Интеграционная шина ibm mq

На этот раз расскажу о своем опыте примирения JMeter и IBM MQ для счастливого тестирования приложений на IBM WAS. Сталкивался с такой задачей, легко она не поддавалась. Хочу помочь сэкономить время всем заинтересованным.

Введение

О проекте: шина данных, множество xml-сообщений, три области обмена (очереди, БД, файловая система), веб-сервисы со своей логикой обработки сообщений. По мере развития проекта тестировать вручную становилось всё сложнее. На помощь был призван Apache JMeter — мощный и опенсорсный, с большим сообществом пользователей и дружелюбным интерфейсом. Легкость кастомизации версии «из коробки» позволяет покрыть любые кейсы, а обещание ведущего разработчика помочь если что (таки помог) окончательно утвердило в выборе.

Приготовление начального контекста

Для взаимодействия с менеджером очередей нужен начальный контекст. Он бывает нескольких типов, вот тут можно почитать подробнее.
Для его создания удобно использовать MQ Explorer:

Рисунок 1: Добавление начального контекста

Выбрать файловый тип контекста и директорию для хранения .bindings файла, который будет содержать описание JNDI-объектов:

Рисунок 2: Выбор типа начального контекста

После чего можно приступать к созданию этих объектов. И начать с фабрики соединений:

Рисунок 3: Создание фабрики соединений

Рисунок 4: Выбор имени фабрики соединений

… и тип Queue Connection Factory:

Рисунок 5: Выбор типа фабрики соединений

Протокол — MQ Client для возможности взаимодействия с MQ удаленно:

Рисунок 6: Выбор протокола фабрики соединений

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

Рисунок 7: Выбор настроек существующей фабрики соединений

В окне выбора параметров достаточно задать три. На вкладке Connection указать имя менеджера очередей и ip стенда с его расположением (порт 1414 оставить):

Рисунок 8: Настройка параметров фабрики соединений

И на вкладке Channels — канал для соединения. Нажать Finish для завершения:

Рисунок 9: Завершение создания фабрики соединений

Теперь создадим подключение к очереди:

Рисунок 10: Создание целевого объекта

Выберем понятное имя (предпочитаю указывать реальное имя очереди) и тип Queue:

Рисунок 11: Выбор имени и типа целевого объекта

По аналогии с Рисунком 7 можно скопировать настройки с существующей очереди. Также жмем Next, если она первая:

Рисунок 12: Выбор настроек существующего целевого объекта

В окне настроек достаточно выбрать имя менеджера и нужную очередь, нажать Finish. После чего повторить необходимое число раз, пока все очереди, нужные для взаимодействия с JMeter, не будут созданы:

Рисунок 13: Завершение создания целевого объекта

Подготовка JMeter

Подготовка JMeter заключается в добавлении библиотек, необходимых для взаимодействия с MQ. Они располагаются в %wmq_home%/java/lib. Скопируйте их в %jmeter_home%/lib/ext перед запуском JMeter.

• com.ibm.mq.commonservices.jar
• com.ibm.mq.headers.jar
• com.ibm.mq.jar
• com.ibm.mq.jmqi.jar
• com.ibm.mq.pcf.jar
• com.ibm.mqjms.jar
• dhbcore.jar
• fscontext.jar
• jms.jar
• jta.jar
• providerutil.jar

Альтернативный список, предложенный polarnik в комментарии с небольшим нюансом: javax.jms-api-2.0.jar вместо jms.jar.
С jms.jar возникает ошибка NoClassDEfFoundError, решение которой нашел тут.

• com.ibm.mq.allclient.jar
• fscontext.jar
• javax.jms-api-2.0.jar
• providerutil.jar

Оба списка библиотек успешно работают с JMeter 5.0 и IBM MQ 8.0.0.4.

Настройка тест-плана

Необходимый и достаточный набор элементов JMeter выглядит так:

Рисунок 14: Тест-план

В примере тест-плана пять переменных. Несмотря на малое их количество, рекомендую заводить отдельные конфигурационные элементы под разные типы переменных. По мере разрастания тестов это существенно упростит навигацию. В данном случае получается два списка. Первый содержит параметры подключения к MQ (см. Рисунок 2 и Рисунок 4):

Рисунок 15: Параметры подключения к MQ

Второй — имена целевых объектов, ссылающихся на очереди:

Рисунок 16: Параметризованные имена очередей

Остается настроить JMS Publisher для загрузки тестового сообщения в исходящую очередь:

Рисунок 17: Настройка JMS Publisher

И JMS Subscriber для вычитывания сообщения из входящей очереди:

Рисунок 18: Настройка JMS Subscriber

Если всё сделано правильно, результат выполнения в листнере наполнится яркими и жизнерадостными зелёными красками.

Читайте также: Ets 2 шины разница

Заключение

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

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

Берегите своё время. И спасибо за внимание.

Видео:[IBM] Lab 26 -Ознакомиться с расширения функционала интеграционной шины support pack’а JobExecution.Скачать

Обеспечьте высочайшую надежность обмена данными

IBM MQ предлагает проверенные средства корпоративного класса для управления сообщениями, позволяющие надежно перемещать информацию между приложениями

Видео:[IBM] Lab 20 - Знакомство с веб-интерфейсом интеграционной шиныСкачать

Многие из самых успешных компаний на планете полагаются на MQ

• 85% списка Fortune 100¹
• 96 из 100 крупнейших международных банков²
• 7 из 10 крупнейших 10 промышленных производителей³
• 46 компаний из рейтинга Global 100⁴
• 7 из 10 крупнейших в мире розничных сетей⁵
• 8 из 10 крупнейших авиакомпаний в мире⁶
• 9 из 10 крупнейших автопроизводителей⁷
• 70% Fortune Global 500⁸

Видео:Интеграционные шиныСкачать

Достоинства MQ

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

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

Сотрудничество

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

Защита

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

Упрощение

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

Видео:Запись вебинара «Интеграция IBM Integration Bus и Apache Kafka»Скачать

Путешествие в мир сервисных корпоративных шин на IBM WebSphere ESB

Данной статьей хочется открыть цикл, посвященный IBM WebSphere ESB (далее — ESB) в разрезе разработки под этот продукт. И, в первую очередь, придется познакомиться поближе с технологиями такого рода.
Enterprise service bus (сервисная шина предприятия) — связующее программное обеспечение, обеспечивающее централизованный и унифицированный событийно-ориентированный обмен сообщениями между различными информационными системами на принципах сервис-ориентированной архитектуры.
Конечно же, можно и без специального ПО (возможно, что-то общее таки придется разработать) строить корпоративную систему основываясь на таком подходе, и то, что в результате получится, называть сервисной шиной. Но в продукте от IBM есть не только уже готовый аппарат для централизованного обмена сообщениями и контроля этого процесса, но и полный набор возможностей для разработки гибких сервис-ориентированных приложений специально под ESB. В итоге, можно выделить следующие возможности и преимущества IBM WebSphere ESB:

• Порядок и единообразие архитектурных связей
• Централизованное управление
• Конфигурация приложений на стороне сервера
• Реализация технологии Service Component Architecture (SCA) в духе принципов сервис-ориентированной архитектуры
• Протоколо-независимость разрабатываемого программного кода
• Широкие возможности конфигурирования шины и приложений

При этом ESB обеспечивает транзакционный контроль, преобразование данных, сохранность и гарантированную доставку сообщений. Доступ ко всем сервисным службам через единую точку позволяет осуществлять конфигурирование коммуникации сервисов централизованно. Так же централизованно можно управлять сбойными событиями для массовой обработки ошибок.
Классическая топология сборки ESB – кластер, обеспечивающий горизонтальную масштабируемость и отказоустойчивость. По официальным рекомендациям, увеличение количества членов кластера увеличивает производительность более эффективно, чем наращивание мощности сервера при stand-alone топологии. Кроме этого, кластер можно перезагрузить (или его часть может отказать) без остановки обслуживания.
Обычно ESB используется как сервисная прослойка в IBM BPM, но вполне может играть ведущую роль в построении модели взаимодействия корпоративных систем как мощный интеграционный аппарат (имеется в виду ESB как надстройка над IBM WebSphere Application Server).
Это, по сути, требуется от ESB, так как это «точка сбора сервисов» — если вам нужен сервис, который будет работать с другими сервисами (возможно, внешними), то интеграцию между этими сервисами логичнее всего сделать именно на ESB. Для внешних или гетерогенных сервисов можно сделать «обертку» ESB-сервисом. Немного проиллюстрируем удобства использования «единого жилья» для сервисов:

Читайте также: Кто производит шины nitto

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

Но намного проще иметь сервис (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-объектов и операций переписывания данных «туда-сюда»).

Читайте также: Шины 185 r14c michelin

Протоколо-независимость программного кода
Как можно было заметить, протоколо-независимость кода достигается путем использования компонент 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

• Свежие записи
  • Нужно ли менять пружины при замене амортизаторов
  • Скрипят амортизаторы на машине что делать
  • Из чего состоит стойка амортизатора передняя
  • Чем стянуть пружину амортизатора без стяжек
  • Для чего нужны амортизаторы в автомобиле

  
  

  источники:

  https://fasad-adelante.ru/integratsionnaya-shina-ibm-mq

  📸 Видео

  Заблуждения об интеграционной шинеСкачать

  

  Начальный курс IBM-MQСкачать

  

  Scalability via IBM MQ Uniform ClusteringСкачать

  

  Интеграция систем на примере шины ESB · Евгений Путилин · ЛАФ #системныйаналитикСкачать

  

  Межсервисное взаимодействие. Очереди сообщенийСкачать

  

  [IBM] Lab 3 -Познакомиться с интерфейсом разработки IBM Integration ToolkitСкачать

  

  IBM Integration Bus V9 practice seminar (RUS). Lab 2Скачать

  

  Необходимость и боль перехода с IBM MQ + RH Fuse на Apache Kafka + Apache Camel / Александр КрыловСкачать