Федеративная архитектура. Шина. Пример интеграции с помощью шины OpenESB

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

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

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

"Зачем так, это же невозможно администрировать" - скажете Вы, и отчасти будете правы.

Но федерация дает нам некоторые преимущества:

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

Обратной стороной медали является:

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

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

Труба обычно связана с инсталляциями системы, и если верить схеме, то должна стоять на одиноком компьютере в поле между Москвой и Уфой, где-то в районе Куйбышевского водохранилища. Одна из задач шины - это надежный транспорт, гарантия доставки сообщения адресату. Если Вам из Москвы придется тянуть кабель до водохранилища, то наверняка где-то он порвется, поэтому труба физически совсем не труба. Логическая сущность трубы - это физически множество экземпляров шины на территории, близкой к инсталляциям, так, чтобы потеряться по пути было сложно (можно представить транспортную компанию с отделениями в населенных пунктах). А как эти экземпляры шины взаимодействуют между собой пользователю ее услуг абсолютно безразлично, поэтому схематично это труба. Некоторые скажут, что есть архитектура шины с единой центральной инсталляцией и  будут  правы, однако чтобы взаимодействовать с единой центральной шиной, всем подключающимся стоит иметь функциональность очереди сообщений (MQ). Т.е. если до центральной инсталляции упал канал, то клиент шины должен уметь подождать. В реальности не все системы готовы держать у себя очередь.

Жизненный кейс интеграции состоит из следующих звеньев: Система 1 -> локальная инсталляция шины 1 -> локальная инсталляция шины N -> веб-сервис интеграции системы N -> система N. 

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

Выбор шины. На рынке много шин, базирующихся на различных технологиях, например, есть дорогая IBM Integration Bus на WebSphere, есть условно бесплатная NServiceBus для WCF. Я предлагаю рассмотреть открытое ПО OpenESB.

Установка JDK.

Заходим на Oracle и качаем JDK (для Windiows jdk-8u102-windows-x64.exe)

Запоминаем папку в которую ставим JDK.

Далее попросит установить JRE.

Далее установим переменные среды. Для этого открываем свойства системы.

Нажимаем на "Переменные среды"

Создаем новую, прописываем JAVA_HOME и путь до JDK.

Через точку с запятой добавляем путь до bin в параметр path.

Установка инсталляции шины.

Заходим на коммьюнити OpenESB и качаем OpenESB SE version 3.0.5. 

Распаковываем архив. Запускаем \OpenESB-Quickstart-Standalone-v305\OpenESB-SE-3.0.5\OE-Instance\bin\openesb.bat

Проверяем работоспособность консоли администратора. Для этого заходим на http://localhost:4848/plugin/webui. Пользователь и пароль по умолчанию admin/admin.

Работает:

Проверяем работоспособность студии. Запускаем студию из \OpenESB-Quickstart-Standalone-v305\OpenESB-SE-3.0.5\OE-Studio\netbeans\bin\openesb.exe

Добавляем сервер:

Указываем Instance. C:\OpenESB\OpenESB-Quickstart-Standalone-v305\OpenESB-SE-3.0.5\OE-Instance

Добавился инстанс:

Возвращаемся в консоль администратора и добавляем библиотеки.

Выбираем из компонент encoderlib.jar

Нажимаем "Start upload". 

Точно также добавляем wsdlextlib.jar.

В разделе компонент консоли администратора аналогично добавляем httpbc-full.jar и bpelse.jar.

Теперь из студии стартуем sun-bpel-engine и sun-http-binding.

Консоль администратора покажет стартованные компоненты:

Разработка BPEL проекта в шине.

Наша задача в шине - получить запрос с некоторыми параметрами от интегрируемой системы, ответить, что получил запрос, обработать его данные, передать его другой интегрируемой системе.

Работаем в студии.

Создаем проект сервис-ориентированной архитектуры, используя BPEL модуль.

Располагаем проект в удобном месте.

Найдем сервис интеграции DIRECTUM.

Скопируем ссылку на wsdl. В моем случае это http://srrngord:8081/IntegrationService.svc?wsdl

Далее в студии OpenESB. Добавим новую внешнюю WSDL.

В студии OpenESB появятся ссылки на сервисы DIRECTUM.

Создаем новый линк на сервисы DIRECTUM. Для этого перетаскиваем иконку PartnerLink на точку справа в BPEL модуле в режиме DESIGN.

Появится окошко, в нем

• Указываем имя линка;
• Видим, что уже выбран WSDL сервисов DIRECTUM;
• Видим, что будет создана обертка для работы с сервисами;
• Видим, что будет создана роль для работы с сервисами.

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

Справа, у нас появился DIRECTUM_IntegrationService со всеми методами. 

Переносим блок вызова сервиса (Invoke) на точку посредине схемы.

В свойствах вызова:

• Именуем его по своему;
• Выбираем наш единственный линк;
• Операция подставится автоматически;
• Нажимаем создать входящие переменные;
• Нажимаем создать исходящие переменные.

Далее вставляем блок определения значения переменных (Assign) перед вызовом сервиса и дважды кликаем на него.

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

Значит на вход надо получить как минимум эти параметры, плюс те которые позволят нам выполнить маршрутизацию (на будущее):

• XMLPackage, string - описание записей справочника в виде XМL-документа в формате обмена;
• ISCode, string - код интегрируемой системы из справочника "Настройки обмена данными с интегрированными системами". Это система отправитель;
• FullSync, boolean - признак установки даты последней синхронизации;
• ReciverCode, string - код системы получателя.

На основе рассуждений выше, создаем WSDLнашего шинного сервиса.

Указать имя. Указать, что это конкретная WSDL.

Далее необходимо указать набить нужные нам параметры.

Получившийся WSDL необходимо притянуть к левой стороне схемы BPEL, сделав из нее PartnerLink.

Имя линка подкорректировать:

Теперь вставляем блок получения данных (Recive).

Кликаем два раза. Выбираем входящий линк.

Теперь можно вернуться к блоку Assign и означить переменные для обращения к сервису DIRECTUM. Стрелки можно тянуть Drag&Drop-ом.

После означивания переменных отправим ответ обратившемуся. Используем блок reply.

Т.к. обращаться в  интегрируемую систему мы планируем асинхронно, то добавим ответ константой:

Выполняем построение проекта.

Разработка композитного приложения на основе BPEL проекта

Чтобы применить наш BPEL проект создаем новый проект - композитное приложение (Composite Application).  

Называем его так, как нам нравится.

Переносим наш BPEL проект в область JBI модулей.

Нажимаем кнопку с молотком (build). Приложение построено. Потом нажимаем на кнопку справа (Deploy)

Видим, что у нас появились QoS (quality of service), т.е. очереди к SOAP портам.

Тестирование в интерфейсе студии OpenESB

Создаем новый тестовый кейс. Выбираем интерфейс на вход шины. Выбираем единственный метод шины.

Заполняем входные параметры. Для примера обновим примечание к записи справочника организации.

  
    
      
           
         ]]>
      
      true
      theString
    
  

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

Но в результат вы увидете ту строку, которую мы рисовали константно:

Проверить отработал ли сервис можно в DIRECTUM:

Таким образом мы разобрали простой пример, как встраивать шину между интегрируемыми системами, где одной из систем является DIRECTUM. На примере OpenESB без регистрации, СМС и кода.

Чтобы посмотреть на WSDL нашего сервиса во вне:

Получается:

Можно протестировать с другого хоста через SOAPUI.