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

В этой лекции описывается создание посреднических (брокерных) компонентов корпоративной сервисной шины (enterprise service Bus, ESB).

Сначала мы опишем место, которое занимает ESB в архитектуре решения, и возможности, которые должен предоставить брокер (раздел 9.1). В следующем разделе – 9.2, "WebSphere Business Integration Message Broker" – коротко описывается концепция брокера сообщений и его основные компоненты. Проектирование компонентов решения описывается в разделе 9.3, "Проектирование компонентов". В следующих пяти разделах детально описывается реализация:

• 9.4, "Реализация наборов сообщений";
• 9.5, "Реализация таблиц баз данных";
• 9.6, "Создание потоков сообщений";
• 9.7, "Создание кода ESQL для потоков сообщений";
• 9.8, "Размещение набора сообщений и потоков".

Например, мы опишем, как следует тестировать и отлаживать потоки сообщений.

9.1 Архитектура

Здесь мы повторим, какое место занимает ESB в архитектуре системы и решения.

Архитектура системы

На рис. 9.1 показана архитектура системы работы с внешними оценщиками. Возвращаясь к обсуждению, приводимому в "Моделирование. Архитектура системы" , "Архитектура системы", поскольку мы используем версию 5 платформы WebSphere, мы решили ограничить ESB шаблоном Extended Enterprise, а для интеграции приложений применить шаблон Application Integration. Шаблон Extended Enterprise отвечает за потоки, идущие к внешним оценщикам и от них. В версии 6 платформы WebSphere мы намереваемся расширить ESB, и включить в нее все компоненты решения, используя надежные соединения между всеми службами.

увеличить изображение
Рис. 9.1. Система работы с внешними оценщиками: связь с продуктами

Задача, которую мы ставим для данной лекции, – это реализация служб маршрутизации и объединения, а также установление соединения между зоной LGI и внешними оценщиками. И снова, исключительно из соображений экономии ресурсов, мы не уделяем внимания реализации шлюза Web-служб, безопасности и различным типам соединения с оценщиками, таким, как браузер, EDI, передача файлов, электронная почта, факс или взаимодействие Web-служб.

Если изучить рис. 9.1 более детально, то видно, что мы используем брокер сообщений для выполнения двух функций, которым соответствуют квадраты с буквами А и В.

1. Предлагаются специфические службы маршрутизации, распределения и объединения для ESB:
   • Брокер отвечает за создание адресов для маршрутизации запросов к конкретным оценщикам с учетом протокола, качества обслуживания и местонахождения оценщика и за размещение запроса в соответствующем транспортном соединении. Если исходная технология соединения не обеспечивает качества обслуживания, необходимого для брокера, то брокер отвечает за наилучшее использование возможностей соединения.

     Технология соединений, используемая брокером, почти всегда связана с ретрансляцией адреса пункта назначения. Это может быть шлюз Web-служб, реализующий для адреса функции прокси из соображений удобства использования и обеспечения безопасности, или DNS-служба, преобразующая имя хоста в IP-адрес. За маршрутизацию отвечает не только брокер. Ему нужно взаимодействовать со службами, относящимися к технологии соединения. Сам же он обеспечивает стабильный интерфейс служб для любых компонентов, которые либо сами реализованы как службы, либо заключены сервисной шиной в службы-оболочки.
   • Частью возможностей, которые дает сервисная шина, являются посреднические функции. Посреднические функции обеспечивают гибкость при установлении соответствий между логическими и физическими интерфейсами служб. Эти функции могут быть простыми, например изменение порядка параметров службы, или сложными, связанными с изменением данных, преобразованием данных и преобразованием типов. Нам потребуются довольно сложные формы посреднических функций, такие, как соответствие "один ко многим" и "многие к одному", т. е. распространение и объединение (агрегация).

     Запрос на оценку принимается ( А ) от процесса RequestExternalAssessment в виде единичного запроса от службы, в котором содержится список потенциальных оценщиков. Список разделяется на отдельные запросы, которые посылаются индивидуальным оценщикам ( В ). Через определенный период времени оценщики возвращают ответы ( С ). Когда согласованный в контракте промежуток времени истекает, брокер объединяет (агрегирует) полученные запросы и вызывает службу ответа, предоставленную процессом RequestExternalAssessm ent, передавая в нее единый список ответов от оценщиков ( D ). Ответы, пришедшие слишком поздно, отбрасываются ( Е ).
2. Еще одна возможность – это обеспечение шины различными формами транспортных протоколов. В WebSphere Business Integration Message Broker поддерживается несколько протоколов связи, и мы собираемся работать в Web-службами, используя протоколы SOAP/http и SOAP/http через WebSphere MQ. Дизайн потоков в брокере позволяет службам связываться, используя любой протокол.

увеличить изображение
Рис. 9.2. Схематическое изображение распределения, агрегации и маршрутизации в брокере

Архитектура решения

Схема последовательностей, приведенная на рис. 9.3, показывает взаимодействия с компонентом ESB proxyAssessorSystem. Взаимодействия, выделенные красным цветом, отражают службы, которые предоставляет компонент proxyAssessorComponent.

увеличить изображение
Рис. 9.3. Схема последовательностей proxyAssessorAutomation

Взаимодействия описаны в табл. 6.1. В табл. 9.1 (созданной на основе табл. 6.2) приводится общий обзор взаимодействий системы proxyAssessorAutomation и идентифицируются WSDL-файлы, определяющие службы. Система proxyAssessorSystem отмечается там, где она отвечает за предоставление служб. Для взаимодействий системы proxyAssessorSystem нужно разработать сервисные потоки, а для других систем – клиентские потоки.

9.2 WebSphere Business Integration Message Broker

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

Брокер относится к уровню служб, обеспечивающих в архитектуре бизнес-интеграции WebSphere связь приложений (Application Connectivity Services)( рис. 9.4). Этот уровень выполняет такие функции, как маршрутизация, посредничество, трансформация и публикация/подписка. Эти функции, как правило, осуществляются "поверх" инфраструктуры обмена сообщениями, такой, как WebSphere MQ.

увеличить изображение
Рис. 9.4. Образец архитектуры бизнес-интеграции WebSphere

При переходе с архитектуры, ориентированной на сообщения, к сервис-ориентированной архитектуре, брокер приобретает новую роль. Он служит мостом между традиционными методами интеграции приложений, использующими адаптеры и промежуточное программное обеспечение, ориентированное на сообщения, и развивающимся миром интеграции служб, использующих сервисные шины. Начиная с версии 5, брокер предлагает интеграцию времени выполнения с транспортным протоколом SOAP/http.

Гибкость модели обмена сообщениями и инструментария брокера означает, что в потоках сообщений брокера могут предоставляться и использоваться SOAP-службы. Именно эту возможность мы собираемся использовать для предоставления SOAP-служб через HTTP, и ее можно легко адаптировать к JMS.

9.2.1 Компоненты брокера сообщений

WebSphere Business Integration Message Broker V5 состоит из следующих компонентов:

• инструментарий Message Brokers Toolkit для WebSphere Studio – новая возможность, заменившая центр управления (Control Center) WebSphere MQ Integrator V2.1, а также имеющая расширенные возможности во многих новых областях;
• менеджер конфигураций (Configuration Manager), содержащий хранилище для конфигураций и сообщений;
• брокеры сообщений (Message broker) – компонент рабочей системы, состоящий из групп выполнения, которые содержат размещенные потоки сообщений;
• функция публикация/подписка;
• менеджеры очередей WebSphere WebSphere MQ, которые формируют базовую транспортную инфраструктуру для WebSphere Business Integration Message Broker;
• прикладные пользовательские программы, которые генерируют сообщения и запрашивают их для проведения трансформации и маршрутизации в другие точки назначения внутри инфраструктуры обмена сообщениями в соответствии с определенными бизнес-правилами.

На рис. 9.5 показана совместная работа этих компонентов.

Рис. 9.5. Компоненты и структура домена брокера

Рабочее место (Broker Workbench)

ИТ-специалист по интеграции использует инструментарий брокера на основе Eclipse для создания и сохранения компонентов решения в локальном рабочем пространстве или в системе контроля версий.

Инструментарий брокера состоит из нескольких дополнений (плагинов) к WebSphere Studio. Эти плагины можно загрузить в уже инсталлированную копию WebSphere Studio, или можно использовать рабочую систему WebSphere Studio, поставляемую на компакт-диске WebSphere Business Integration Message Broker.

Менеджер конфигураций

Для размещения решений ИТ-специалист сохраняет готовые наборы сообщений и потоки сообщений в хранилище менеджера конфигураций, которое представляет собой базу данных DB2. Затем их можно разместить в одном или нескольких брокерах. Брокеры, которые представляют собой компоненты рабочей системы, доступны для различных платформ, в том числе:

• для Windows;
• нескольких версий UNIX , включая Linux;
• z/OS.

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

На рис. 9.6 в разделе Domain Connections (Соединения доменов) есть только один домен брокеров. В редакторе связей доменов показана информация для соединения с WBRK_BROKER, которую мы сконфигурировали в разделе 7.2.5, "Инсталляция и конфигурирование брокера сообщений". Связь домена брокеров представляет собой связь клиента WebSphere MQ с менеджером очереди, который находится в подчинении у менеджера конфигурации. Домен брокеров для нашего решения состоит из менеджера конфигурации и только одного брокера с соответствующими им базами данных.

Рис. 9.6. Инструментарий, связанный с доменом брокеров

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

Брокер

Сам брокер состоит из нескольких компонентов ( рис. 9.7). Процесс брокера осуществляет управление несколькими процессами и мониторинг их, каждый из которых называется DataFlowEngine (система потока данных). Каждый процесс DataFlowEngine соответствует административной группе выполнения (execution group). Группа выполнения может обрабатывать одновременно несколько размещенных потоков сообщений в соответствии с многонитевой моделью выполнения. В одном брокере может работать несколько групп размещения, и ими можно управлять по отдельности (т. е. размещать, запускать, останавливать, удалять и т. д.).

Рис. 9.7. Структура брокера

Потоки часто начинаются с узла MQInput, а это означает, что поток сообщений начинается с чтения сообщения из очереди. Это сообщение затем передается дальше по направлению графа с выполнением логики, которую моделирует поток. Еще один часто применяемый тип входного узла – это узел HTTPInput. Этот узел используется для получения потоковых данных (data streams) протокола HTTP. Мы используем в нашей реализации оба типа входных узлов – и MQInput и HTTPInput.

Потоки сообщений в брокере могу использовать базы данных, а также выполнять поиск и сохранение данных в потоках. Поддерживается несколько продуктов – баз данных, в зависимости от конкретной платформы. С брокером часто используются продукты DB2 и Oracle. В Windows также поддерживается SQL Server. Для нашей базы данных мы использовали DB2.

Модель сообщений

На рис. 9.8 показан общий обзор различных компонентов модели сообщений. Каждый из них будет подробно описан ниже.

увеличить изображение
Рис. 9.8. Общий обзор модели сообщений

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

Наборы сообщений

Проект набора сообщений (message set project) – это контейнер для всех ресурсов, относящихся к одному-единственному набору сообщений. Набор сообщений (message set) – это логическая группа сообщений и объектов, их составляющих (элементов, типов, групп). В содержимое набора сообщений входит:

• файл с одним набором сообщений (messageSet.mset);
• один или несколько файлов определений сообщений (.mxsd);
• нуль и более файлов категорий сообщений (.category).

Единственный файл набора сообщений (.mset) содержит информацию, которая является общей для всех сообщений набора. Эта информация редактируется при помощи редактора наборов сообщений.

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

Сообщения могут группироваться в категории из соображений удобства и упрощения генерации WSDL. Группы определяются в файлах .category.

Средства импорта сообщений

Файлы определений сообщений могут создаваться и заполняться с помощью одного из имеющихся средств импорта. Средства импорта доступны для ХML DTD, XML-схем, структур C и структур COBOL. Средства импорта можно применять либо с помощью команды mqsicreatemsgdefs, либо с помощью инструментария Message Brokers Toolkit.

Существует также утилита командной строки mqsimigratemsgsets для переноса наборов сообщений WebSphere MQ Integrator V2.1 в наборы сообщений WebSphere Business Integration Message Broker V5.

Редакторы сообщений

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

Средства экспорта сообщений

Существуют средства генерации, позволяющие экспортировать наборы сообщений в стандартные внешние форматы. К этим форматам относятся:

• словарь сообщений для размещения в брокере;
• XML-схема для проверки передаваемых XML-сообщений;
• описания Web-служб (WSDL) для клиентов Web-служб;
• документация (в виде HTML).

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