IBM Integration Bus и с чем его едят
Добрый день, уважаемый читатель.
Существует такой класс продуктов как ESB. Как упоминается в Википедии это — связующее программное обеспечение, обеспечивающее централизованный и унифицированный событийно-ориентированный обмен сообщениями между… и далее по тексту. Примеров таких ESB не так много и применяются они достаточно узко. Одним из таких ESB является IBM Integration Bus (IIB), до 9 версии именовался IBM Message Broker.
Несколько лет назад я столкнулся с таким продуктом как IIB. Пытаясь понять, что это за зверь, я обнаружил, что упоминаний о нём в русскоязычном интернете крайне мало. Данный пост позволит представить эту самую интеграционную шину во всей красе и помочь таким же ищущим как я.
В России данных продукт применяется достаточно ограниченно в банковской, страховой и логистической сфере. Именно там, где большой документооборот и высокие требования к надёжности. Также недавно большой газовый проект искал специалистов по IIB. Как там применяется шина я до конца не знаю, но возможно для телеметрии (MQTT).
Суть данного программного обеспечения связать N систем между собой, даже если эти системы имеют абсолютно разные интерфейсы и форматы. Скажем система X создаёт в своей БД запись в таблице и при её появлении мы хотим вызывать REST API другого приложения с JSON внутри, где будут передаваться поля нашей записи, и проставлять метку об отправке в другой таблице приложения X. И это всё с поддержкой транзакционности и гарантированной доставкой. (Когда одно приложение лезет в базу другого это плохо, но такое бывает!) Вот так выглядит типичная задача для потока IIB.
На чём ведётся разработка в IIB
Одной из самых удобных вещей в IIB это графическое программирование. Когда в среде Eclipse на поле вытягиваешь с палитры ноды, соединяешь их между собой и вжух, всё работает.
Но писать код обычно тоже нужно. Для трансформации сообщений или логики основной язык это ESQL (Extend SQL). Синтаксически похож на PL/SQL, но заточен для работы с древовидными структурами данных.
Также есть поддержка нескольких языков программирования:
Очень наглядно, в отличии от того, если делаешь это в коде.
Выше я затронул вопрос трансформации сообщений, но до этого сообщение нужно получить. Для этого на политре есть достаточно большое количество Input узлов. Самые распространённые в моей практике это:
До последних версий IIB был неразрывно связан с IBM MQ, но в последней версии IIB (IBM App Connect Enterprise 11) это уже не требуется.
Так как это первый пост, я его сделал ознакомительным. Если будет интерес к теме, я продолжу повествование.
Путешествие в мир сервисных корпоративных шин на IBM WebSphere ESB
Порядок
Чем большего размера система, тем более важен в ней порядок и единообразие. Если речь идет о комплексе систем большого предприятия, то его точно уж можно назвать системой большого размера. Конечно, всегда можно найти администратора, держащего в голове схему взаимодействия сотни серверов, или кучу томов несвязанной документации по каждому программному модулю, где описано, с чем и как он взаимодействует. 
Но намного проще иметь сервис (ESB), который позволяет проводить все взаимодействие через себя. При таком подходе часть архитектуры взаимодействия в любой подсистеме уже понятна – нет бардака в связях между системами, серверами и приложениями: все связано с ESB и ESB связано со всем.
Централизованное управление
Всегда удобнее производить настройку систем централизованно – будь то конфигурирование, адаптация к переезду серверов, обеспечение отказоустойчивости, распределение нагрузки, обработка ошибок либо мониторинг и аналитика.
Например, при переезде сервера БД не нужно залезать в конфигурацию всех существующих серверов приложений, и в настройки конкретных приложений в частности – достаточно иметь одну переменную среды в ESB, в которой указывается адрес БД, и тогда изменения нужно будет выполнить всего в одной точке.
Или же если одна из внешних систем была недоступна длительное время, а ни один запрос к ней не должен потеряться – можно воспользоваться сервисом обработки сбойных событий для «вбрасывания» недошедших сообщений тогда, когда это будет удобно.
Если вам нужно регулировать количество одновременных запросов к какой-либо системе, либо мониторить эти запросы, анализировать нагрузку, искать узкие места – вам нужно в центр управления обмена сообщениями – в консоль ESB-сервера.
Конфигурация на стороне сервера
«Единое жилье» для сервисов, с точки зрения конфигурирования, позволяет достичь нескольких полезных целей. Во-первых, это повторное использование конфигурации (по аналогии с повторным использованием кода и модулей, которое так полезно в SOA), поскольку разные модули и приложения могут использовать одни и те же параметры соединения с БД, ресурсы, параметры аутентификации, переменные среды и прочее.
Во-вторых, при конфигурировании на стороне сервера именно среда работы приложения во многом может на него влиять, что позволяет переносить приложения между разными контурами (тестовым и продуктивным), тюнинговать и даже исправлять баги без внесения изменений в приложение.
Если использовать все эти преимущества, приложения получают способности истинного хамелеона – они настолько гибкие, что стают частью среды, в которой работают, и при этом привносят свой важный функционал.
Но гибкость приложений под IBM WebSphere ESB не ограничивается средой их работы. Громадный вклад в это делают возможности разработки. Поскольку, системы не только нужно иметь, где запускать, но еще нужно разрабатывать и дорабатывать, эти интересные пункты упускать нельзя:
SCA
Эта архитектура основывается на принципе предоставления компонентой своей функциональности в виде сервиса, доступного другим компонентам. В рамках одного модуля компонентами выступают программные блоки (java код), полностью реализующие некий функционал, описанный соответствующим интерфейсом. Логика выполнения компонент реализуется связыванием их в структуру по интерфейсам и reference’ам (Partner Reference).
Такую структуру модуля очень удобно разрабатывать, проверять, развивать, изменять и поддерживать. Атомарность функционала, реализованного в компонентах, позволяет оперировать компонентами в целом, не опускаясь до уровня кода. С другой стороны, она логично необходима ввиду выполнения имплементаций компонент в транзакционном контексте.
У каждой компоненты есть интерфейс(ы), имплементацию которого она предоставляет. Таким образом, связывая между собой компоненты, нет необходимости знать их внутренние особенности – достаточно того, что они реализуют необходимые интерфейсы.
Посредством данной архитектуры также можно решить все задачи, требующие параллельной работы, без «ручного» управления потоками (например, можно выполнять асинхронные вызовы нескольких компонент с отсроченным ответом).
Не java-компоненты, например, типов Export и Import, позволяют предоставлять сервисы для внешнего использования либо использовать внешние сервисы соответственно; компонента Mediation Flow обеспечивает низкоуровневый доступ к сообщениям, которыми обмениваются другие компоненты и позволяет производить различные преобразования при работе с гетерогенными интерфейсами.
Помимо интерфейсов, очень полезные возможности предоставляет IBM business object framework. Бизнес-объекты (БО), представлены xsd-схемами, используются как объекты для передачи данных в интерфейсах, как между компонентами, так и для коммуникации между модулями. Они же напрямую интегрируются, например, в wsdl-схему для описания веб-сервисов. То есть, например, если модуль «А» предоставляет свой функционал в виде веб-сервиса, модулю «Б» для его использования достаточно подключить интерфейс и готовые БО, и он сможет в полной мере работать с таким сервисом без создания каких-либо дополнительных java-объектов для передачи данных. БО также удобно использовать при обмене данными с БД, если эти данные используются другими компонентами (это, конечно, идет в разрез с паттерном «DAO», но избавляет от лишних java-объектов и операций переписывания данных «туда-сюда»).
Протоколо-независимость программного кода
Как можно было заметить, протоколо-независимость кода достигается путем использования компонент Export и Import. Поскольку связь с этими компонентами идет по интерфейсам и reference’ам, программный код полностью независим от используемого для взаимодействия протокола. Один и тот же функционал можно легким движением сделать доступным по любому количеству поддерживаемых протоколов и по любым нужным интерфейсам. На следующем рисунке показано добавление экспорта с SCA привязкой к компоненте, которая уже предоставляет свой интерфейс как HTTP, JMS и Web-сервис.
Удобства очевидны – гибкость, универсальность, повторное использование кода, быстрота разработки и модификации.
Кстати, SCA привязка использует особый протокол и предназначена для сообщения между модулями в рамках одного сервера/кластера. Взаимодействие через эту привязку менее ресурсоемкое и более быстрое по сравнению с другими протоколами.
Конфигурирование
Конфигурирование сервера и приложений осуществляется через IBM console сервера.
В ESB, как и в IBM WebSphere в общем, довольно много специфических возможностей и артефактов. Например, при использовании тех же импортов и экспортов, можно «на лету» конфигурировать end-point’ы соответствующих сервисов. Для вызовов сервисов можно настраивать policy set’ы с разнообразными правилами (например, можно установить поддержку механизма WS-AT, который позволяет вызывать веб-сервис в той же транзакции, в которой работает клиент; но транзакционность – это уже тема для полной статьи), устанавливать параметры аутентификации, подключать сертификаты и прочее.
Через конфигурирование можно настроить некоторые механизмы автоматической реакции на исключительные ситуации (например, автоматическое повторение выполнения компонент при ошибках). Можно «на лету» настроить трассировку компонент или изменить уровни логирования. Также доступен сервис управления сбойными событиями, который можно осознанно использовать для массовой обработки ошибок.
Ну и, конечно же, можно настроить много чего другого согласно спецификации Java2EE, которая, иногда довольно строго, реализована в IBM Application Server.
Все вышеприведенное утверждает ESB как удобный, мощный и гибкий интеграционный аппарат, пусть и не всегда легкий в освоении. В дальнейшем нужно всего лишь научиться им пользоваться.
В статье использованы следующие изображения: 1 2 3 4 5
IBM ACE прямо из коробки совместим с несколькими платформами виртуализации, и Docker является ярким примером этого. С помощью ACE вы можете загрузить из глобального репозитория Docker среду выполнения IBM ACE и запустить ее локально. Поскольку административная консоль ACE встроена прямо в среду выполнения, после того, как образ Docker станет активным на вашем локальном компьютере, вы можете выполнять все команды настройки и администрирования, необходимые для полной активации любого потока сообщений или развертывания любого файла BAR. Фактически, вы можете создавать потоки сообщений, которые являются микросервисами, и напрямую упаковывать эти микросервисы в развертываемый объект Docker. Поскольку потоки сообщений и файлы BAR могут содержать файлы политик, эта конфигурация узла может быть автоматической, и для завершения развертывания приложения не требуется вмешательства человека.
Содержание
Характеристики
IBM представляет следующие особенности как ключевые отличия продукта IBM ACE по сравнению с другими отраслевыми продуктами, которые предоставляют услуги Enterprise Service Bus:
IBM поставляет программное обеспечение IIB либо в виде традиционного программного обеспечения, устанавливаемого в вашем локальном офисе, либо в локальной среде IBM Cloud Private, либо в управляемой IBM облачной среде. Шина интеграции в облачной среде сокращает капитальные затраты, повышает доступность приложений и оборудования и перекладывает навыки управления средой шины интеграции на облачных инженеров IBM. Это дает конечным пользователям возможность сосредоточиться на разработке решений, а не на установке, настройке и управлении программным обеспечением IIB. Предложение предназначено для совместимости с локальным продуктом. В рамках ограничений облачной среды пользователи могут использовать одни и те же инструменты разработки как для облачного, так и для локального программного обеспечения, и созданные активы могут быть развернуты в любом из них.
История
Продукт был добавлен к семейству WebSphere и переименован в «WebSphere MQ Integrator» в версии 2.1. После 2.1 номера версий стали более синхронизированными с остальной частью семейства WebSphere и перешли на версию 5.0. Имя изменено на «Посредник сообщений WebSphere Business Integration Message» (WBIMB). В этой версии среда разработки была переработана с использованием Eclipse, а поддержка веб-служб была интегрирована в продукт. Начиная с версии 6.0 этот продукт известен как «WebSphere Message Broker». Версия 7.0 WebSphere Message Broker была анонсирована в октябре 2009 г., а версия 8.0 WebSphere Message Broker анонсирована в октябре 2011 г.
В апреле 2013 года IBM объявила, что продукт WebSphere Message Broker подвергается очередному ребрендингу с изменением названия. IBM Integration Bus версии 9 включает новые узлы, такие как узел Decision Service, который обеспечивает маршрутизацию на основе содержимого на основе механизма правил и требует продукта IBM WebSphere Operational Decision Management. Продукт IBM WebSphere Enterprise Service Bus был прекращен с выпуском IBM Integration Bus, и IBM предлагает переходные лицензии для перехода на IBM Integration Bus. Лицензия WebSphere Message Broker Transfer для WebSphere Enterprise Service Bus позволяет клиентам обменивать некоторые или все свои лицензионные права на WebSphere Enterprise Service Bus на лицензионные права WebSphere Message Broker. После передачи лицензии право на использование WebSphere Enterprise Service Bus будет сокращено или прекращено. Это отражает отказ от лицензионных прав на WebSphere Enterprise Service Bus во время обмена. IBM объявила на Impact 2013, что срок службы WESB истечет через пять лет, и дальнейшая разработка функций продукта WESB производиться не будет.
Составные части
IBM Integration Bus состоит из следующих компонентов:
Как работает IBM Integration Bus
IBM Integration Bus включает в себя набор инструментов мониторинга производительности, который визуально отображает текущую пропускную способность сервера, показывая различные метрики, такие как прошедшее время и время ЦП, таким образом, чтобы сразу привлечь внимание к узким местам производительности и резким скачкам спроса. Вы можете детализировать подробные сведения, такие как ставки для отдельных соединителей, а инструменты позволяют соотносить информацию о производительности с изменениями конфигурации, чтобы вы могли быстро определить влияние конкретных изменений конфигурации на производительность.
В версии 7 и ранее основным способом моделирования и анализа общих текстовых и двоичных сообщений был контейнер, называемый набором сообщений и связанным с ним парсером «MRM». Начиная с версии 8 такие сообщения моделируются и анализируются с использованием новой открытой технологии, называемой DFDL, от Open Grid Forum. Это стратегическая технология IBM для моделирования и анализа общих текстовых и двоичных данных. Парсер MRM и наборы сообщений остаются полностью поддерживаемой частью продукта; Чтобы использовать наборы сообщений, разработчик должен включить их, поскольку они отключены по умолчанию, чтобы стимулировать внедрение технологии DFDL.
IBM Integration Bus поддерживает формирование трафика на основе политик, что обеспечивает большую прозрачность для системных администраторов и оперативный контроль над рабочей нагрузкой. Формирование трафика позволяет системным администраторам удовлетворять потребности, когда количество новых конечных точек (таких как мобильные и облачные приложения) экспоненциально увеличивается, регулируя доступные системные ресурсы для удовлетворения этого нового спроса, задерживая или перенаправляя трафик, чтобы справиться с пиками нагрузки. Мониторинг трафика позволяет отправлять уведомления системным администраторам и другим заинтересованным сторонам бизнеса, что повышает осведомленность бизнеса и позволяет обнаруживать тенденции.
Обзор
Разработчик создает потоки сообщений в циклическом рабочем процессе, возможно, более гибком, чем при разработке большинства других программ. Разработчики создадут поток сообщений, сгенерируют BAR-файл, развернут поток сообщений, содержащийся в BAR-файле, протестируют поток сообщений и, при необходимости, повторите для достижения надежной функциональности.
Положение на рынке
Ожидаемая производительность
IBM публикует отчеты о производительности для WebSphere Message Broker, в которых приводятся примерные показатели пропускной способности. Производительность зависит от размеров сообщений, объемов сообщений, сложности обработки (например, сложности преобразования сообщений), емкости системы (ЦП, память, сеть и т. Д.), Версии программного обеспечения и уровней исправлений, настроек конфигурации и других факторов. Некоторые опубликованные тесты демонстрируют, что скорость передачи сообщений превышает 10 000 в секунду в определенных конфигурациях.
Доступны узлы потока сообщений
Разработчик может выбрать из многих предварительно разработанный поток сообщений «узлов», которые используются для создания потока сообщений. Узлы имеют разное назначение. Некоторые узлы отображают данные из одного формата в другой (например, Cobol Copybook в канонический XML). Другие узлы оценивают содержимое данных и по-разному направляют поток в зависимости от определенных критериев.
Типы узлов потока сообщений
Существует много типов узлов, которые можно использовать при разработке потоков сообщений; доступны следующие варианты технологии преобразования узлов:
Локализация
IBM Integration Bus в распределенных системах была локализована для следующих культур:
Узоры
Версия 7 представила шаблоны, которые:
IBM Integration Bus и с чем его едят
Добрый день, уважаемый читатель.
Существует такой класс продуктов как ESB. Как упоминается в Википедии это — связующее программное обеспечение, обеспечивающее централизованный и унифицированный событийно-ориентированный обмен сообщениями между… и далее по тексту. Примеров таких ESB не так много и применяются они достаточно узко. Одним из таких ESB является IBM Integration Bus (IIB), до 9 версии именовался IBM Message Broker.
Несколько лет назад я столкнулся с таким продуктом как IIB. Пытаясь понять, что это за зверь, я обнаружил, что упоминаний о нём в русскоязычном интернете крайне мало. Данный пост позволит представить эту самую интеграционную шину во всей красе и помочь таким же ищущим как я.
В России данных продукт применяется достаточно ограниченно в банковской, страховой и логистической сфере. Именно там, где большой документооборот и высокие требования к надёжности. Также недавно большой газовый проект искал специалистов по IIB. Как там применяется шина я до конца не знаю, но возможно для телеметрии (MQTT).
Суть данного программного обеспечения связать N систем между собой, даже если эти системы имеют абсолютно разные интерфейсы и форматы. Скажем система X создаёт в своей БД запись в таблице и при её появлении мы хотим вызывать REST API другого приложения с JSON внутри, где будут передаваться поля нашей записи, и проставлять метку об отправке в другой таблице приложения X. И это всё с поддержкой транзакционности и гарантированной доставкой. (Когда одно приложение лезет в базу другого это плохо, но такое бывает!) Вот так выглядит типичная задача для потока IIB.
На чём ведётся разработка в IIB
Одной из самых удобных вещей в IIB это графическое программирование. Когда в среде Eclipse на поле вытягиваешь с палитры ноды, соединяешь их между собой и вжух, всё работает.
Но писать код обычно тоже нужно. Для трансформации сообщений или логики основной язык это ESQL (Extend SQL). Синтаксически похож на PL/SQL, но заточен для работы с древовидными структурами данных.
Также есть поддержка нескольких языков программирования:
Очень наглядно, в отличии от того, если делаешь это в коде.
Выше я затронул вопрос трансформации сообщений, но до этого сообщение нужно получить. Для этого на политре есть достаточно большое количество Input узлов. Самые распространённые в моей практике это:
До последних версий IIB был неразрывно связан с IBM MQ, но в последнич версиях IIB это уже не требуется. Но часть функционала без MQ работать не будет, поэтому основная схема работы предполагает установку MQ.
Так как это первый пост, я его сделал ознакомительным. Если будет интерес к теме, я продолжу повествование.
Построение простого flow в IBM App Connect (Integration Bus)
Make legacy great again
Назовём наше приложение «Increment Integer»
На flow размещаются компоненты из палитры:
Палитра компонентов
Каждый flow для работы должен иметь как минимум входной компонент. Такие компоненты в палитре отмечаются зелёной полоской слева. В нашем случае мы будем использовать компонент HTTPInput. Для его размещения на flow выбираем в палитре вкладку HTTP, зажимаем правую кнопку мыши на HTTPInput и перетаскиваем компонент на flow editor:
Flow editor с HTTPInput
Вкладка «Input Message Parsing»
В данном случае будем использовать JSON.
Вкладка «Error Handling»
Остальные настройки оставляем по умолчанию. После получения сообщения необходимо его обработать. За это отвечает компонент Compute, который находится на палитре во вкладке Transofmation:
После сохранения редактора компонент Compute будет показывать ошибку, так как к нему не привязан файл ESQL.
Вернёмся во flow. Чтобы передать сообщение из HTTPInput в Compute, их необходимо соединить через терминалы.
Чтобы вернуть ответ клиенту, ставим компонент HTTPReply:
Теперь заходим в Compute и в функции Main пишем следующий код:
SET OutputRoot.JSON.Data.testNumber = InputRoot.JSON.Data.testNumber + 1;
Приложения деплоят на интеграционные сервера, которые, в свою очередь, поднимаются на Integration Nodes. Если тулкит показывает, что ноды у вас нет, нужно её создать. Для этого запускаем IBM Integration Console (IBM App Connect Enterprise Console) и вбиваем там команду:
Далее жмём на барник и выбираем внутри него приложение, которое хотим задеплоить:
Далее надо сбилдить барник, для этого жмём кнопку “Build and Save…”.
Порт находится в параметре HTTPListener->HTTPConnector->ListenerPort
Проверяем в SoapUI:
Готово! В следующий раз опишу обработку исключений и логирование в IIB.
