Из IBM WebSphere Developer Technical Journal.

Введение

В 2006 году я написал статью "Динамическая маршрутизация времени исполнения в WebSphere Enterprise Service Bus" (developerWorks, 2006), в которой рассматривались ограничения динамической маршрутизации в WebSphere Enterprise Service Bus V6.0.1 и демонстрировались некоторые приемы их обхода. К счастью, в WebSphere Enterprise Service Bus Version 6.0.2 (здесь и далее WebSphere ESB) эти ограничения были устранены и добавились новые функциональные возможности, которые значительно облегчают динамическую маршрутизацию в соединении с реестром сервисов.

В данной статье я расскажу о механизме динамической оконечной точки, реализованном в WebSphere ESB V6.0.2 (WebSphere ESB), и о том, как можно его использовать. Я также продемонстрирую использование примитивов-посредников (mediation primitives), новой функциональной возможности Version 6, для поддержки двух различных форм разрешения оконечной точки, которую вы можете использовать в сочетании с механизмом динамической оконечной точки для обеспечения динамической маршрутизации.

В начало

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

В предыдущей статье я продемонстрировал, как с помощью WebSphere Integration Developer V6.0.1 (Integration Developer) создать модуль-посредник WebSphere ESB, поддерживающий только статическую маршрутизацию. То же самое (по аналогии) можно сделать при помощи Integration Developer V6.0.2, поэтому я не буду повторять эту процедуру в данной статье.

Процесс создания статической маршрутизации в предыдущей статье включал в себя определение проекта Business Integration Library, называемого Resources, содержащего WSDL для Web-сервиса BigEcho (см. листинг 1). Для примеров в данной статье необходимо создать библиотеку, используя Integration Developer V6.0.2.

                
<?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:9080/BigEcho/services/BigEcho"/>
    </wsdl:port>
 </wsdl:service>
</wsdl:definitions>
			

На рисунке 1 показана показана компоновочная схема Integration Developer, получаемая после создания модуля-посредника. Можно увидеть компоненты экспорта (слева) и импорта (справа), а также компонент-посредник (в центре).

На рисунке 2 показано отображение операций для компонента-посредника в редакторе Mediation Flow. Интерфейс компонента-посредника BigEcho представлен слева, а ссылка компонента-посредника BigEchoPartner - справа.

На рисунке 3 показана простая схема потока данных запроса, в котором узел Input (представляющий запрос от Export1), связывается с интерфейсом компонента-посредника. Интерфейс компонента-посредника соединяется непосредственно со ссылкой компонента-посредника. Узел Callout (представляющий запрос к Import1) связывается со ссылкой компонента-посредника. Такая компоновка передает входящий запрос непосредственно из Export в Import без обработки. Обратите внимание на различия во внешнем виде артефактов в редакторе Mediation Flow версий 6.0.1 и 6.0.2; в 6.0.2 представления экспорта и интерфейса, а также ссылки и импорта, различны. Я поясню важность этого далее.

На рисунке 4 показана простая схема обработки ответа, в которой узел CalloutResponse (представляющий ответ от Import1) связан со ссылкой компонента-посредника, который непосредственно соединен с интерфейсом компонента-посредника, связанного с узлом InputResponse (представляющим ответ в Export1). Такая схема передает входящий ответ непосредственно из Import в Export.

Как говорилось в предыдущей статье, после сохранения модуля-посредника и развертывания его на тестовом сервере (либо WebSphere ESB, либо WebSphere Process Server Version 6.0.2) можно приступить к тестированию модуля-посредника. Самый простой способ сделать это - использовать Web Services Explorer. Реализация используемого нами сервиса BigEcho выполняется в той же тестовой среде, что и модуль-посредник StaticRoute, поэтому в консоли тестовой среды отображается сообщение +++ Got to BigEcho. Это говорит о том, что модуль-посредник активизировал сервис BigEcho от имени запросчика сервиса, в данном случае Web Services Explorer.

Конечно, StaticRoute довольно скучен, поскольку на самом деле он ничего не делает. Более того, если нужно изменить статический адрес, указанный в Import, то придется изменить модуль-посредник и повторно развернуть его. Однако данный пример демонстрирует слабую связь (decoupling) запросчика сервиса и провайдера, показывает преемственность между версиями 6.0.1 и 6.02, и намечает тему нашего дальнейшего обсуждения.

В начало

Динамические оконечные точки

После завершения работы с модулем-посредником StaticRoute перейдите к потоку данных запроса в редакторе Mediation Flow и выберите узел Callout, связанный со ссылкой компонента-посредника. Затем перейдите в закладку Properties и выберите Details, как показано на рисунке 5.

Обратите внимание на флажок с названием Use dynamic endpoint if set in the message header (Использовать динамическую оконечную точку, если это установлено в заголовке сообщения). Он означает, что если сообщение запроса в потоке данных посредника запроса содержит адрес в заголовке, сообщение передается провайдеру по указанному адресу.

В реальности все несколько сложнее. Если данное свойство отключено, будет использоваться статический адрес из компонента импорта, связанного со ссылкой; если компонента импорта, предоставляющего адрес, не существует, возникает исключение. При включенном свойстве (по умолчанию), если адреса в заголовке нет и имеется компонент импорта, используется статический адрес из последнего; опять же, если компонента импорта, предоставляющего адрес, не существует, генерируется исключение.

Важно понимать, что при включенном свойстве наличие компонента импорта не обязательно. Поскольку этот компонент не обязателен, вам не нужно связывание (binding). Это очень мощная возможность, поскольку она позволяет использовать различные адреса не только для доступа к провайдерам с одним и тем же связыванием, но с различными адресами, но также для доступа к провайдерам с различными типами связывания.

Важно отметить еще ряд моментов. В сообщении запроса (являющегося на самом деле объектом Service Message Object (SMO)) адрес динамической оконечной точки, идентифицирующий нужного провайдера, должен находиться в месте, указанном XPath-выражением /headers/SMOHeader/Target/address. Далее, адрес должен быть корректным URI одного из поддерживаемых связываний. В настоящее время поддерживаемыми связываниями являются SOAP/HTTP, SOAP/JMS и SCA (по умолчанию - SCA-модули). Ссылки на дополнительную информацию по механизму динамической оконечной точки приведены в разделе "Ресурсы".

Механизм динамической оконечной точки делает динамическую маршрутизацию очень простой и мощной - необходимо всего лишь поместить корректный адрес в /headers/SMOHeader/Target/address для передачи запросов нужному провайдеру, поддерживающему любое допустимое связывание. Так как же указать адрес в заголовке? К счастью, WebSphere ESB предлагает несколько вариантов для вставки адреса в заголовок:

• Можно использовать пользовательский примитив-посредник (mediation primitive), аналогичный продемонстрированному в предыдущей статье.
• Можно с помощью примитива-посредника DatabaseLookup извлечь значение ключа из сообщения запроса и использовать его для поиска соответствующего адреса путем вставки адреса в запрос.
• Можно использовать примитив-посредник MessageElementSetter (новая возможность V6.0.2).
• Можно использовать примитив-посредник EndpointLookup (новая возможность V6.0.2).

В данной статье я опишу последние два варианта.

В начало

Динамическая маршрутизация с использованием MessageElementSetter

Давайте рассмотрим подход к динамической маршрутизации, использующий механизм динамической оконечной точки и новый примитив-посредник MessageElementSetter.

1. Во-первых, создайте модуль-посредник под названием MESRouter, ссылающийся на Resources Library в своих зависимостях, используя прием, продемонстрированный в руководстве "Начало работы с WebSphere Enterprise Service Bus и WebSphere Integration Developer". На рисунке 6 показана схема компоновки Integration Developer, созданная в результате следующих действий:
   • создание модуля-посредника, содержащего компонент-посредник, автоматически названный Mediation1;
   • добавление к модулю-посреднику компонента экспорт, автоматически названного Export1;
   • назначение интерфейса BigEcho компоненту Export1;
   • генерирование связывания Web-сервисов (HTTP) для Export1;
   • запись Export1 в Mediation1;
   • добавление в Mediation1 ссылки, содержащей определение интерфейса BigEcho.
   
   
   Рисунок 6. Схема компоновки для MESRouter
   
   
   

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

2. Откройте редактор Mediation Flow и отобразите операцию так, как показано на рисунке 2.
3. Откройте схему потока данных запроса и поместите в него примитив-посредник MessageElementSetter. Соедините интерфейс компонента-посредника с входом примитива, а также выход примитива со ссылкой компонента-посредника, как показано на рисунке 7.
   
   Рисунок 7. Прохождение запроса MESRouter
   
   
   
4. Нажмите MessageElementSetter1, перейдите на вкладку Properties и выберите Details. Вы увидите таблицу троек {Target, Type, Value}, которые определяют, какие элементы (и в какое значение) устанавливаются в сообщении. Нажмите кнопку Add для отображения диалогового окна Add/Edit, показанного на рисунке 8.
5. Нажмите Custom XPath и задайте месторасположение в SMO, куда будет помещаться адрес.
   
   Рисунок 8. Диалоговое окно Add/Edit
   
   
   
6. В диалоговом окне Build the XPath Expression разверните headers => SMOHeader => Target и выберите адрес, как показано на рисунке 9, а затем нажмите кнопку OK, чтобы вернуться в диалоговое окно Add/Edit.
   
   Рисунок 9. Диалоговое окно конструктора выражений XPath
   
   
   
7. 7. Введите адрес провайдера, которому перенаправляется сообщение. Для этого первого теста введите значение Web-сервиса SOAP/HTTP, приведенное в WSDL-файле (листинг 1), а затем нажмите кнопку Finish в диалоговом окне Add/Edit. Должны отобразиться свойства примитива, как показано на рисунке 10.
   
   Рисунок 10. Свойства MessageElementSetter1
   
   
   
8. Соедините поток данных запроса точно так, как показано для StaticRoute на рисунке 4.
9. Сохраните поток данных модуля-посредника и сам модуль-посредник, разверните MESRoute в тестовой среде.
10. Протестируйте модуль, используя Web Services Explorer. Реализация сервиса BigEcho выполняется в той же тестовой среде, что и модуль-посредник MESRoute, поэтому он отображает сообщение +++ Got to BigEcho в консоли тестовой среды, показывая, что модуль-посредник активизирует сервис BigEcho.

Для демонстрации гибкости механизма динамической оконечной точки создадим еще один провайдер сервисов. Вместо связывания SOAP/HTTP, используемого в сервисе BigEcho (листинг 1), здесь используется связывание SOAP/JMS.

Проще всего сделать это, используя Integration Developer для создания бизнес-модуля, выполняющегося на сервере WebSphere Process Server. Подробное описание процесса выходит за рамки данной статьи, но модуль должен иметь компонент экспорта со связыванием Web-сервисов (SOAP/JMS) и Java™-компонент, выводящий при активизации сообщение +++++ Got to BigEchoJMS на консоль. В листинге 2 приведен WSDL-файл, сгенерированный программой Integration Developer для описания сервис-провайдера с именем BigEchoJMS.

                
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions name="Export1_BigEchoJms_Service" 
targetNamespace="http://big.com/Binding"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:Port_0="http://big.com"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:this="http://big.com/Binding"
xmlns="http://schemas.xmlsoap.org/wsdl/">
  <wsdl:import namespace="http://big.com" location="BigEcho.wsdl"/>
  <wsdl:binding name="Export1_BigEchoJmsBinding" type="Port_0:BigEcho">
    <soap:binding style="document" 
transport="http://schemas.xmlsoap.org/soap/jms"/>
    <wsdl:operation name="echo">
      <soap:operation/>
      <wsdl:input name="echoRequest">
        <soap:body use="literal"/>
      </wsdl:input>
      <wsdl:output name="echoResponse">
        <soap:body use="literal"/>
      </wsdl:output>
      <wsdl:fault name="BadBoyException">
        <soap:fault name="BadBoyException" use="literal"/>
      </wsdl:fault>
    </wsdl:operation>
  </wsdl:binding>
  <wsdl:service name="Export1_BigEchoJmsService">
  <wsdl:port name="Export1_BigEchoJmsPort"
binding="this:Export1_BigEchoJmsBinding">
      <soap:address
location="jms:/queue?destination=jms/Export1&
	connectionFactory=jms/Export1QCF&
	targetService=Export1_BigEchoJmsPort"/>
    </wsdl:port>
  </wsdl:service>
</wsdl:definitions>
				

1. Откройте редактор Mediation Flow для MESRouter и перейдите на вкладку Property, а затем выберите Details для MessageElementSetter1. Вы должны увидеть нечто похожее на рисунок 10.
2. Измените значение поля для /headers/SMOHeader/Target/address так, чтобы оно содержало JMS-адрес модуля BigEchoJMS (он будет аналогичен указанному в атрибуте location элемента address в листинге 2).
3. Сохраните модуль-посредник и перезапустите его.
4. Если вы протестируете MESRouter опять, то увидите в консоли тестовой среды сообщение +++++ Got to BigEchoJMS, показывающее, что модуль-посредник активизировал провайдер BigEchoJMS. У вас изменился не только адрес провайдера, но и тип связывания с провайдером!

Еще одним преимуществом использования примитива-посредника MessageElementSetter является то, что WebSphere ESB V6.0.2 разрешает поддерживать такие свойства, как значение адреса провайдера, помещенное в SMO-заголовок. Это делает такие свойства доступными в консоли администратора WebSphere ESB, в результате их можно изменять после развертывания без повторного его выполнения.

На рисунке 11 показано, как можно было бы поддерживать адрес провайдера для MessageElementSetter1 в модуле-посреднике MESRouter. После этого можно найти и изменить адрес под названием MessageElementSetter1.targetAddress в консоли администратора. Это позволяет после развертывания модуля-посредника MESRouter изменить адрес с провайдера BigEcho на провайдера BigEchoJMS. Данная функциональная возможность позволяет легко решать такие административные задачи, как изменение целевого адреса при перемещении сервис-провайдеров из одной среды в другую. Дополнительная информация по поддерживаемым свойствам приведена в разделе "URI примера динамической оконечной точки" в WebSphere Integration Developer Information Center.

Существует еще одна функциональная возможность MessageElementSetter, о которой необходимо знать. При создании назначения (target) элемента message в диалоговом окне Add/Edit (рисунок 8), вы оставили в поле Type значение String, чтобы поле Value могло быть желаемой строковой константой. Однако поле Type имеет дополнительные варианты, одним из которых является copy, позволяющий копировать значение из любого места сообщения (также указываемого XPath-выражением) в желаемое место (в данном случае - адрес, используемый механизмом динамической оконечной точки). Эта возможность используется для осуществления некоторых форм маршрутизации, зависящей от содержимого.

В начало

Динамическая маршрутизация с использованием EndpointLookup

Теперь давайте рассмотрим новый примитив-посредник EndpointLookup, созданный специально для использования механизма динамической оконечной точки. Одной из ключевых характеристик динамической маршрутизации, выполняемой ESB, является возможность управления с использованием метаданных. Это позволяет создавать более целостные сервис-ориентированные решения, тесно интегрированные в общую модель управления предприятием. Основой этого подхода является реестр сервисов. Роль реестра сервисов в сервис-ориентированных решениях выполняет программа IBM WebSphere Service Registry and Repository (здесь и далее называемая Service Registry and Repository). Ссылки на информацию о Service Registry and Repository приведены в разделе "Ресурсы". Хотя Service Registry and Repository охватывает широкое разнообразие задач, я сконцентрируюсь на динамической маршрутизации на основе метаданных, поддерживаемых программой Service Registry and Repository.

Примитив-посредник EndpointLookup позволяет компоненту-посреднику использовать Service Registry and Repository для реализации управляемой метаданными динамической маршрутизации без применения специального программного кода. Примитив-посредник EndpointLookup позволяет компоненту-посреднику извлекать информацию оконечной точки из Service Registry and Repository. Дополнительная информация приведена в разделе "Примитив-посредник EndpointLookup" WebSphere ESB Information center. Информация оконечной точки сервиса может иметь отношение к Web-сервисам или к SCA-модулям экспорта с Web-сервисами или SCA-связываниями.

Примитив запрашивает в Service Registry and Repository информацию оконечной точки, соответствующую критериям, указанным в свойствах примитива. Обязательными являются только критерии, имеющие отношение к типу WSDL-порта провайдера, но критерии также могут включить определенные пользователем свойства и классификации. Примитив также имеет свойство match policy (политика соответствия), указывающее примитиву возвращать одно или все соответствия. В случае одного соответствия примитив автоматически вставляет адрес оконечной точки в SMO-заголовок для управления механизмом динамической оконечной точки. При опции «все соответствия» необходимо вставить в поток данных дополнительный примитив, который будет обрабатывать соответствия и выбирать из них один для управления механизмом динамической оконечной точки.

Теперь давайте рассмотрим, возможно, самое простое, но, тем не менее, интересное - использование примитива-посредника EndpointLookup. Для реализации примера необходимо установить Service Registry and Repository, включая последний пакет исправления ошибок (см. раздел "Ресурсы"). Вы должны также определить Service Registry and Repository в WebSphere ESB или WebSphere Process Server, на котором планируете выполнять модуль-посредник, использующий EndpointLookup; это необходимо даже для тестовой среды в Integration Developer.

1. Для настройки экземпляра Service Registry and Repository в среде сервера откройте консоль администратора, выберите Service Integration => WSRR definitions и нажмите кнопку New. На рисунке 12 показано определение экземпляра Service Registry and Repository, TestWSRR, используемого для демонстрации EndpointLookup. Обратите внимание на то, что псевдоним аутентификации установлен на незащищенное соединение с Service Registry and Repository.
   
   Рисунок 12. Определение Service Registry and Reposity в тестовой среде
   
   
   
2. Загрузите или опубликуйте WSDL-документ для провайдера BigEcho, как показано на рисунке 13.
   
   Рисунок 13. Опубликованный WSDL-документ для провайдера BigEcho
   
   
   

   Приложение Service Registry and Repository понимает WSDL-документы и создаст логические элементы, определенные в WSDL-документе. На рисунке 14 показан созданный тип WSDL-порта, на рисунке 15 показано связывание, на рисунке 16 - сервис, а на рисунке 17 - порт.

   
   
   Рисунок 14. Тип порта для провайдера BigEcho
   
   
   
   
   Рисунок 15. Связывание для провайдера BigEcho
   
   
   
   
   Рисунок 16. Сервис для провайдера BigEcho
   
   
   
   
   Рисунок 17. Порт для провайдера BigEcho
   
   
   
3. Далее создайте новый модуль-посредник WSRRRouter, который использует примитив-посредник EndpointLookup. В редакторе компоновки выполните описанные выше инструкции для MESRouter, чтобы создать модуль-посредник, похожий на изображенный на рисунке 6.
4. Откройте редактор Mediation Flow, отобразите операцию и создайте поток данных ответа, как делали это для MESRouter. В потоке данных запроса поместите примитив-посредник EndpointLookup. Соедините интерфейс компонента-посредника с входом примитива, а выход примитива - со ссылкой компонента-посредника (как показано на рисунке 18).
   
   Рисунок 18. Поток данных запроса WSRRRouter
   
   
   
5. Откройте свойства для EndpointLookup1, как показано на рисунке 19. Установите поля Name и Namespace для типа порта в значения, используемые для типа порта BigEcho. Можно нажать кнопку Browse для упрощения этого процесса. Оставьте поле Version пустым. Необходимо указать используемое приложение Service Registry and Repository; примитив будет извлекать информацию о доступе к этому Service Registry and Repository из среды сервера. Для данного примера введите TestWSRR в качестве Registry Name. Наконец, в поле Match Policy выберите вариант Return one matching endpoint. Сохраните поток данных посредника и модуль-посредник, затем разверните модуль в тестовой среде Integration Developer.
   
   Рисунок 19. Свойства EndpointLookup1
   
   
   
6. Протестируйте WSRRRouter, используя Web Services Explorer. После получения запроса примитив-посредник запрашивает все порты, соответствующие указанному в свойствах типу порта. Поскольку BigEcho является единственным соответствием в данном тесте, в запросе возвращается информация об оконечной точке, и примитив помещает адрес оконечной точки в заголовок для управления механизмом динамической оконечной точки. Вы должны увидеть сообщение +++ Got to BigEcho в консоли тестовой среды, показывающее, что модуль-посредник активизировал провайдер BigEcho.

Давайте рассмотрим следующий сценарий.

1. Загрузите WSDL-документ для провайдера BigEchoJMS в Service Registry and Repository. Если вы исследуете содержимое реестра, то увидите WSDL-документы для провайдера BigEchoJMS и провайдера BigEcho, как показано на рисунке 20.
   
   Рисунок 20. WSDL для BigEchoJMS и BigEcho
   
   
   

   Поскольку оба провайдера реализуют одинаковый тип порта, в реестре определяется только тип порта BigEcho. Будут, конечно, существовать новые связывание, сервис и порт, как показано на рисунках 21, 22 и 23 соответственно.

   
   
   Рисунок 21. HTTP и JMS-связывания
   
   
   
   
   Рисунок 22. Сервисы BigEcho и BigEchoJMS
   
   
   
   
   Рисунок 23. Порты BigEchoJMS и BigEcho
   
   
   
2. Без каких-либо изменений в WSRRRouter выполните тест опять. Возможно, в консоли тестовой среды вы увидите сообщение +++++ Got to BigEchoJMS, показывающее, что модуль-посредник активизировал провайдера BigEchoJMS вместо BigEcho.

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

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

1. Выберите Details, затем перейдите в закладку Advanced.
2. Нажмите кнопку Add в разделе User Properties, добавьте свойство под названием Preferred, тип string и значение yes.
3. Сохраните поток данных и модуль посредника.
   
   Рисунок 24. Дополнительный критерий для WSRR-запроса
   
   
   
4. Добавьте измененное свойство для нужного провайдера. В консоли Service Registry and Repository выберите Ports => BigEcho => Custom Properties. Нажмите кнопку New, добавьте новое свойство под названием Preferred со значением yes и сохраните информацию. Результаты показаны на рисунке 25.
   
   Рисунок 25. Измененное свойство для порта BigEcho
   
   
   
5. Снова протестируйте WSRRRouter. Вы увидите сообщение +++ Got to BigEcho в консоли тестовой среды, показывающее, что данный модуль-посредник активизировал провайдера BigEcho вместо BigEchoJMS.

И опять вы осуществили это изменение, используя возможности метаданных! Естественно, можно таким же образом гарантировать выбор провайдера BigEchoJMS путем установки значения свойства Preferred в yes на его порте, а свойства Preferred порта BigEcho - в любое значение, кроме yes (либо удалив это свойство).

В начало

Резюме

В данной статье были рассмотрены некоторые новые функциональные возможности WebSphere ESB V6.0.2. Они значительно расширили границы использования WebSphere ESB для выполнения управляемой метаданными маршрутизации. Однако в данной статье рассматриваются только основы. Подумайте о комбинировании примитивов-посредников MessageElementSetter и EndpointLookup для обеспечения управляемой метаданными маршрутизации в сочетании с настроенными администратором значениями по умолчанию. Можно также добавить к этой комбинации примитив-посредник MessageFilter для поддержки нескольких типов портов. Используя WebSphere ESB V6.0.2, вы можете выполнять мощную и гибкую динамическую маршрутизацию, которая значительно расширяет возможности ваших сервис-ориентированных решений.

Ресурсы

Научиться

• Оригинал статьи "IBM WebSphere Developer Technical Journal: Dynamic routing improvements in WebSphere Enterprise Service Bus V6.0.2" (EN).
  
  
• WebSphere Enterprise Service Bus: Информация о продукте.(EN)
  
  
• Начало работы с WebSphere Enterprise Service Bus и WebSphere Integration Developer (developerWorks, 2006): Узнайте, как разработать поток данных через посредника, предоставляя базовый Web-сервис; разработать промежуточный поток данных для соединения с этим сервисом, развернуть и протестировать эти потоки при помощи тестовых возможностей инструментария и автономного JSP-приложения.(EN)
  
  
• Разработка пользовательских объектов-посредников для WebSphere Enterprise Service Bus (developerWorks, 2006): Узнайте, как использовать пользовательские объекты-посредники в среде WebSphere Integration Developer V6 для WebSphere Enterprise Service Bus V6.(EN)
  
  
• Спецификации: Service Component Architecture (SCA) и Service Data Objects (SDO): Прочтите спецификации.(EN)
  
  
• WebSphere Enterprise Service Bus Information Center: Полная документация по продукту.(EN)
  
  
• Динамическая маршрутизация во время исполнения в WebSphere Enterprise Service Bus (developerWorks, 2006): Узнайте, как реализовать динамическую маршрутизацию во время исполнения для Web-сервисов (SOAP/HTTP и SOAP/JMS) в WebSphere Enterprise Service Bus Version 6.0.1.
  
  
• Динамический выбор оконечной точки: WebSphere Integration Developer Information Center.(EN)
  
  
• Маршрутизация сообщений при установленном свойстве динамической оконечной точки: WebSphere Integration Developer Information Center.(EN)
  
  
• URI примера динамической оконечной точки: WebSphere Integration Developer Information Center.(EN)
  
  
• Создание Enterprise Service Bus с WebSphere ESB, часть 3 (developerWorks, 2007): Необходимо упомянуть.
  
  
• Введение в IBM WebSphere Service Registry and Repository, часть 1 (developerWorks, 2006): Познакомьтесь с концепциями и возможностями IBM WebSphere Service Registry and Repository, включая роль Service Registry and Repository в жизненном цикле SOA.
  
  
• Создание гибких объектов-посредников для ESB с использованием WebSphere Message Broker и WebSphere Service Registry and Repository (developerWorks, 2006): ): Узнайте, как использование WebSphere Service Registry and Repository в WebSphere Message Broker Enterprise Service Bus может помочь вам создавать более гибкие и менее хрупкие объекты-посредники для ESB, делая ваш бизнес менее восприимчивым к проблемам, связанным с изменениями. (EN)
  
  
• Установка пакета исправления ошибок WebSphere Service Registry and Repository Fix pack: Инструкции по установке пакета исправления ошибок.(EN)
  
  
• Примитив-посредник EndpointLookup: WebSphere Enterprise Bus Information Center.(EN)
  
  
• developerWorks WebSphere ESB-ресурсы: Статьи, файлы для загрузки и другая техническая информация по WebSphere ESB.(EN)
  
  
• Раздел developerWorks WebSphere Web Services: Статьи, файлы для загрузки и другая техническая информация по WebSphere Web Services.(EN)
  
  
• Раздел developerWorks WebSphere Web SOA: Статьи, файлы для загрузки и другая техническая информация по WebSphere и SOA.(EN)
  
  
• Раздел developerWorks WebSphere Web Business Integration: Статьи, файлы для загрузки и другая техническая информация по WebSphere Business Integration. (EN)
  
  

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

• WebSphere Service Registry and Repository V6.0 Fix Pack 1: Загрузите пакет исправления ошибок.(EN)
  
  

Обсудить

• Примите участие в обсуждении материала на форуме.
  
  

Об авторе

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

Комментарии

В начало

Содержание

• Введение
• Статическая маршрутизация для SOAP/HTTP
• Динамические оконечные точки
• Динамическая маршрутизация с использованием MessageElementSetter
• Динамическая маршрутизация с использованием EndpointLookup
• Резюме
• Ресурсы
• Об авторе
• Комментарии