Реализация. Создание корпоративной сервисной шины

9.4 Реализация наборов сообщений

Для создания наборов сообщений, содержащих определения сообщений для всех интерфейсов, перечисленных в табл. 9.1, нам нужно выполнить шесть шагов:

1. Преобразовать WSDL-определения сообщений в схемы.
2. Создать проект набора сообщений.
3. Создать набор сообщений.
4. Импортировать схему интерфейсов.
5. Преобразовать схемы в определения сообщений.
6. Настроить определения сообщений для создания SOAP-конвертов

9.4.1 Преобразование сообщений из wsdl-файлов в схемы

WebSphere Studio Application Development Integration Edition или Rational Software Architect – это самые лучшие инструменты для преобразования WSDL-файлов в схемы, поскольку оба эти инструмента имеют специализированный WSDL-редактор и редактор схем. WebSphere Business Integration Message Broker содержит только редактор схем.

1. В WebSphere Studio Application Development Integration Edition создайте новые файлы схем для каждого WSDL-файла, который нужно преобразовать.

   Создавайте файлы схем с теми же именами, но с расширениями .xsd. Существует мастер, который поможет вам это сделать. Выберите пункт меню File (Файл) XML XML Schema. Присвойте схеме имя и нажмите Finish (Готово) ( рис. 9.14).

   

   
   Рис. 9.14. Создание нового файла схемы в Integration Edition
   Сохраните файлы в директории с именем wsdl. На рис. 9.15 показано дерево проектов в WebSphere Studio Application Development Integration Edition с несколькими файлами WSDL и .xsd.
   

   
   Рис. 9.15. Некоторые из файлов схем и WSDL в проекте
2. Существует два типа WSDL-файлов. Часть имеет встроенные полные определения сообщений, а часть ссылается на схему Businessitems.xsd. Проще всего начать с файлов с полными определениями сообщений. После их конвертирования становится понятно, как следует редактировать оставшиеся файлы:
   • Возьмем в качестве примера файл AssessorAvailability(3).wsdl и скопируем все, что находится между тегами <wsdl:types> и <\wsdl:types>. Откройте файл AssessorAvailability(3).xsd, выделите все начиная с <schema ... и по <\schema> (пример 9.6) и замените эти данные скопированными определениями.

     <schema xmlns="http://www.w3.org/2001/XMLSchema" 
       targetNamespace="http://www.ibm.com" 
       xmlns:test="http://www.ibm.com">
     </schema>

     Пример 9.6. Выделенное выражение schema
   • Файл должен сохраниться без ошибок. В качестве дополнительного задания, приведите в порядок выражение schema и оставшуюся часть файла (первая часть файла схемы показана в примере 9.7):

     <?xml version="1.0" encoding="UTF-8"?>
     <schema elementFormDefault="qualified"
     targetNamespace="http://broker.lgi.itso.assessavail"
     xmlns="http://www.w3.org/2001/XMLSchema"
     xmlns:intf="http://broker.lgi.itso.assessavail" >
       <element name="requestAssessorAvailability">
         <complexType>
           <sequence>
             <element name="claimID" nillable="true" type="int" />
             <element name="location" nillable="true" type="string" />
             <element name="responseTime" nillable="true" type="string" />
             <element name="requiredDate" nillable="true" type="string" />
             <element name="makeOfCar" nillable="true" type="string" />
             <element name="assessorList" nillable="true"
                type="intf:AssessorList" />
           </sequence>
         </complexType>
       </element>
     ... продолжение ...

     Пример 9.7. Приведенный в порядок файл схемы
     • были удалены дублирующиеся пространства имен;
     • поскольку http://www.w3.org/2001/XMLSchema является пространством имен по умолчанию, все префиксы xsd: можно удалить;
     • убедитесь, что целевое пространство имен уникально в пределах набора сообщений и совпадает с пространством имен, ассоциированным с префиксом, применяемым для всех встроенных сложных типов.
   Внимание! Мы предлагаем, чтобы при импортировании схемы в MRM брокера в каждом создаваемом вами файле схемы был свой префикс целевого пространства имен. Мы использовали префиксы flxx, где хх – номер потока. Изменение префикса не влияет на семантику схемы, но позволяет повысить удобство чтения и избежать путаницы. Лучший способ избежать проблем с именами – это управлять пространствами имен и определениями типов на всем протяжении интеграционного пространства, но такое во многих случаях просто невозможно по организационным и историческим причинам. В данном проекте у нас есть несколько конфликтов имен, отражающих проблемы реального мира, и мы решаем задачу по устранению этих конфликтов.

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

9.4.2 Создание проекта набора сообщений

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

Сколько же проектов наборов сообщений нам нужно создать для хранения всех нужных нам наборов сообщений? Мы можем поместить все определения в один набор и можем помещать каждое определение в свой собственный набор сообщений.

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

увеличить изображение
Рис. 9.16. Организация наборов сообщения в брокере

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

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

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

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

На практике в ходе интеграции корпоративных приложений лучше всего свести к минимуму переработку имеющегося кода, а для связывания частей использовать возможности интеграционных серверов, таких, как WebSphere Business Integration Message Broker.

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

В табл. 9.8 показано, как мы распределили определения сообщений.

Все шло прекрасно, пока мы не начали писать код ESQL. Мы обнаружили, что, хотя компилятор ESQL нормально воспринимал использование нескольких наборов сообщений, в функции автоматического выполнения имелась проблема, в основном объясняющаяся тем, что на все наши типы ссылалось одно сообщение SOAP-конверт. Функция автоматического выполнения могла предлагать специализированные элементы Body из одного набора сообщений. Вообще-то мы могли бы продолжать и без правильно работающей функции автоматического выполнения, используя несколько наборов сообщений для разрешения конфликтов имен и типов. Мы приняли решение учесть все это, разрешить конфликты имен и использовать один набор сообщений. Мы ожидаем, что версия 6 WebSphere Business Integration Message Broker будет содержать усовершенствования, улучшающие его работу в данной области, что сделало бы подход с несколькими наборами сообщений более предпочтительным.

Теперь наша цель – разрешить конфликты имен, возникающие из-за использования одного набора сообщений в WebSphere Business Integration Message Broker без изменения WSDL-определений Web-служб.

Создайте один проект набора сообщений с именем Assessor Messageset.

1. Откройте инструментарий брокера и выберите перспективу Broker Application Development (Разработка приложений брокера).
2. Выберите пункт меню File (Файл) New (Новый) Message Set Project (Проект набора сообщений). Введите имя Assessor Messageset, нажмите Next (Далее) и Finish (Готово).
3. Вы можете сразу создать и набор сообщений. Мы будем использовать другой мастер ( рис. 9.17).

Рис. 9.17. Создание нового проекта набора сообщений

9.4.3 Создание набора сообщений

После создания проекта набора сообщений создайте набор сообщений, который будет содержать все определения сообщений.

1. Щелкните правой кнопкой мыши по проекту набора сообщений, выберите пункт меню New (Новый) Message Set (Набор сообщений) и введите имя набора сообщений proxyAssessorMessages:
   • Установите флажок Use namespaces (Использовать пространства имен) и нажмите Next (Далее) ( рис. 9.18).
     

     
     Рис. 9.18. Флажок Use namespaces (Использовать пространства имен)
   • Установите флажок XML Wire Format Name (Имя формата XML Wire) и нажмите Finish (Готово) ( рис. 9.19).
     

     
     Рис. 9.19. Флажок XML Wire Format Name (Имя формата XML Wire)
   Здесь вы можете изменить имя формата XML Wire, но мы оставили в этом поле значение XML1. Это имя ассоциируется с форматом передачи данных XML, который используется для всех определений сообщений, входящих в набор сообщений. Это имя формата должно использоваться везде и должно совпадать с именем формата во входящем сообщении (если оно указано). Очень легко проглядеть несовпадение имен форматов в сообщениях, а это не даст потоку работать. Формат XML Wire можно настраивать, и мы увидим это позже. Настроенный формат должен быть идентичен для всех определений сообщений, входящих в набор сообщений.
   

   
   увеличить изображение
   Рис. 9.20. Свойства набора сообщений
   Теперь новый набор сообщений создан, и на экране отображается файл messageSet. mset.
2. Укажите в поле Default Wire Format (Формат передачи XML по умолчанию) значение XML1 (формат по умолчанию используется, если формат не указан во входящем сообщении или во входном узле потока сообщений).
3. В разделе Properties Hierarchy (Иерархия свойств) файла messageSet.mset раскройте пункт Physical properties (Физические свойства) XML1.
4. В разделе Details (Подробно) файла messageSet.mset:
   • Установите флажок Suppress doctype (Не использовать типы документов). Объявления DTD не нужны. Система основывается на схемах, а не на DTD.
   • Очистите поле Root Tag Name (Имя корневого тега).

Мы используем SOAP-сообщения, где имя корневого тега должно быть Envelope. Также система потенциально может применять встроенные сообщения. Неразумно применять жестко определенное имя корневого тега при использовании встроенных сообщений.

увеличить изображение
Рис. 9.21. Настройка генерации XML