Esb шина данных java

По мере развития любой компании появляются новые бизнес-процессы, требующие автоматизации, усложняются схемы взаимодействия IT-систем. Таким образом, по прошествии нескольких лет многие IT-директора сталкиваются с проблемой: в состав используемого ПО входит целый набор «проверенных временем» систем, но при этом взаимодействие между ними реализовано лишь частично, плохо структурировано, не подчинено единому стандарту, а необходимость создания новой интеграции IT-систем почти всегда требует использования собственных разработок или приобретения еще одного дорогостоящего программного продукта.

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

В начале 2000 годов на рынке программного обеспечения стали появляться решения, сформировавшие кластер под названием Сервисная шина масштаба предприятия (Enterprise Service Bus, ESB), или сокращенно Шина Данных. Шина Данных – это, в первую очередь, концепция, элемент архитектуры IT-ландшафта, используемый для решения задачи интеграции разрозненных информационных систем в единый программный комплекс с централизованным управлением передачей информации и применением сервис-ориентированного подхода.

Enterprise Service Bus (ESB)

Архитектура ESB строится на 3 компонентах:

• набор коннекторов
• очередь сообщений
• платформа

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

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

К основным преимуществам современных ESB-решений относятся:

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

Пример действующего решения

К настоящему времени на рынке представлено более двух десятков шин данных, однако наибольшее распространение получили следующие решения:

• Integration Bus (IBM)
• Oracle Service Bus (Oracle)
• BizTalk (Microsoft)
• ActiveMatrix Service Bus (TIBCO)
• MuleESB (MuleSoft)
• JBoss Fuse ESB (Red Hat)

По результатам проведенного анализа различных Шин Данных нашей компанией был сделан выбор в пользу программного продукта JBoss Fuse. В число критериев входили такие вопросы как: наличие широкого спектра адаптеров (включая работу с web-сервисами), возможности маршрутизации и трансформации сообщений, оркестровка, поддерживаемые протоколы обмена, удобство администрирования, стоимость приобретения и поддержки. Данное решение по своим функциональным характеристикам не уступает аналогам от IBM, Oracle и Microsoft, но при этом доступно для бесплатного использования (лицензия приобретается только на поддержку).

На рисунке показан пример реализации web-сервиса, который по запрошенному идентификатору выдает из базы данных информацию о клиенте. Задача решена в инструменте редактирования JBoss Fuse, входящем в состав Jboss Fuse ESB.

Заключение

Внедрение Шины Данных в IT-ландшафт организации позволяет не только структурировать, привести к единому стандарту и упростить поддержку процедур обмена информацией между системами, но также снизить временные затраты на интеграцию новых подсистем и, как следствие, сократить стоимость поддержки и развития всей IT-инфраструктуры компании.

Видео:Плюсы и минусы сервисной шины данных I Enterprise service bus (ESB) I kt.teamСкачать

Обзор ESB-систем ServiceMix и Fuse

Представляю вашему вниманию небольшой обзор систем ESB (Enterprise Service Bus) на основе Apache Camel: Apache ServiceMix и Red Hat JBoss Fuse. Эти две системы построены на одних и тех же компонентах и обладают схожими возможностями. Более того, в большинстве случаев, они взаимозаменяемы. Apache ServiceMix разрабатывается open-source сообществом, Red Hat JBoss Fuse компанией Red Hat. По большей части, это одни и те же люди.

Для начала, разберемся что такое ESB и зачем системы такого класса используются в информационной инфраструктуре предприятий. На современных предприятиях используется всё большей приложений различного класса: ERP, CRM, BPM, DWH, ECM и ещё множество трех-буквенных аббревиатур. Все эти приложения используют для интеграции различные протоколы и различные форматы данных. Для того чтобы связать все эти системы между собой и используется ESB.

Читайте также: Что изменится в велосипедной шине после ее накачивания ответ

Итак ESB-системы выполняют следующие основные функции:

• подключение по различным протоколам
• маршрутизация запросов и сообщений
• преобразование данных

Обе системы Apache ServiceMix и Red Hat JBoss Fuse имеют в своей основе следующие компоненты:

Apache Camel реализует непосредственно функции ESB на основе паттернов EIP (Enterprise Integration Patterns). Apache Camel имеет свой DSL для задач интеграции. Существует несколько его реализаций: Spring DSL, Blueprint DSL, Java DSL, Groovy DSL, Scala DSL. Так же, в состав Apache Camel входит более 100 компонент отвечающих за подключение по различным протоколам и преобразование данных.

Apache ActiveMQ — система очередей сообщений. Реализуется различные функции обмена сообщениями: обмен сообщениями по моделям отправитель-получатель (sender-receiver), издатель-подписчик (publish-subscribe), синхронный обмен (request-response), персистентные сообщения (persistent message), поддержку транзакций, включая распределенные XA-транзакции.

Apache CXF — библиотека, реализующая функции веб-сервисов, включая SOAP и REST.

Apache Karaf — платформа для запуска приложений на основе OSGi. OSGi позволяет устанавливать, удалять и обновлять различные модули (bundle) без перезапуска всей системы и без остановки зависимых модулей. Это особенно важно в корпоративной инфраструктуре, где остановки компонент крайне нежелательны, так как могут привести к прямым финансовым потерям. В системах на основе OSGi всё является модулем (bundle): библиотеки, маршруты интеграции, подключения к ресурсам.

Для Red Hat JBoss Fuse существует альтернативный вариант запуска. Вместо Apache Karaf можно использовать Red Hat JBoss EAP.

Обе системы поддерживают отказоустойчивую (failover) конфигурацию по модели master-slave.

Встает резонный вопрос, если Apache ServiceMix и Red Hat JBoss Fuse состоят из одних и тех же компонент, реализуют одну и ту же функциональность, разрабатываются одними и теми же людьми, то зачем платить больше? Кроме указанных выше компонентов, Red Hat JBoss Fuse включает несколько дополнительных, упрощающих работу администратора и позволяющих управлять кластером.

Hawtio — графическая консоль управления, позволяющая подключать различные плагины, в том числе для управления Apache Camel, Apache ActiveMQ, Fuse Fabric и т.д… Несмотря на то что Hawtio не входит в состав Apache ServiceMix, она может быть установлена на любую версию Apache ServiceMix двумя командами.

Fuse Fabric — система управления кластером на основе Fabric8. Позволяет управлять конфигурациями узлов кластера группами или по отдельности. Поддерживает версионирование конфигурации. Так же как и Hawtio, Fabric8 может быть легко установлена на Apache ServiceMix. Кроме того, для Apache ServiceMix имеется альтернативный способ управления кластером на основе Apache Karaf Cellar.

При приобретении подписки Red Hat JBoss Fuse вы получаете поддержку от компании Red Hat и возможность использовать инструмент мониторинга Red Hat JBoss Operation Network. Для Apache ServiceMix можно использовать RHQ, open-source аналог Red Hat JBoss Operation Network. Как альтернатива, для целей мониторинга Apache ServiceMix может быть использован Apache Karaf Decanter.

Apache ServiceMix’у тоже есть чем похвастаться. В состав последних версий Apache ServiceMix входит движок бизнес-процессов Activiti, который позволяет реализовывать персистентные интеграционные процессы. Apache Camel не предназначен для реализации интеграционных взаимодействий разнесенных по времени. Если при использовании Apache Camel без Activiti происходит сбой, то все не отправленные данные будут потеряны, все транзакции откатятся. В то же время, с использованием Activiti мы можем сохранить состояние процесса в БД. Red Hat для решения подобных задач предлагает использовать Red Hat JBoss BPM Suite.

Основным преимуществом Apache ServiceMix перед Red Hat JBoss Fuse является то что Apache ServiceMix включает более новые версии компонент.

Что выбрать? Универсального ответа нет. Если у вас есть команда профессионалов, имеющих опыт работы с Apache ServiceMix или Red Hat JBoss Fuse, то можно задействовать все преимущества Apache ServiceMix и заплатить при этом меньше. Если же опыт отсутствует, то поддержка от компании Red Hat не будет лишней.

Кроме рассмотренных систем, на основе Apache Camel существует Talend ESB. Но я не имел практического опыта работы с ней, поэтому в обзор она не включена.

Видео:Шины данных и интеграции | ESB шина данных | Интеграция 1С ERPСкачать

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

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

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

Читайте также: Шины лето 2017 топ

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

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

Но намного проще иметь сервис (ESB), который позволяет проводить все взаимодействие через себя. При таком подходе часть архитектуры взаимодействия в любой подсистеме уже понятна – нет бардака в связях между системами, серверами и приложениями: все связано с ESB и ESB связано со всем.

Централизованное управление
Всегда удобнее производить настройку систем централизованно – будь то конфигурирование, адаптация к переезду серверов, обеспечение отказоустойчивости, распределение нагрузки, обработка ошибок либо мониторинг и аналитика.

Например, при переезде сервера БД не нужно залезать в конфигурацию всех существующих серверов приложений, и в настройки конкретных приложений в частности – достаточно иметь одну переменную среды в ESB, в которой указывается адрес БД, и тогда изменения нужно будет выполнить всего в одной точке.
Или же если одна из внешних систем была недоступна длительное время, а ни один запрос к ней не должен потеряться – можно воспользоваться сервисом обработки сбойных событий для «вбрасывания» недошедших сообщений тогда, когда это будет удобно.
Если вам нужно регулировать количество одновременных запросов к какой-либо системе, либо мониторить эти запросы, анализировать нагрузку, искать узкие места – вам нужно в центр управления обмена сообщениями – в консоль ESB-сервера.

Конфигурация на стороне сервера
«Единое жилье» для сервисов, с точки зрения конфигурирования, позволяет достичь нескольких полезных целей. Во-первых, это повторное использование конфигурации (по аналогии с повторным использованием кода и модулей, которое так полезно в SOA), поскольку разные модули и приложения могут использовать одни и те же параметры соединения с БД, ресурсы, параметры аутентификации, переменные среды и прочее.

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

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

Читайте также: Киа серато давление в шинах r17

Но гибкость приложений под 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

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

  💥 Видео

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

  

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

  

  Apache Kafka урок 1. Зачем нужна, что это? RabbitMQ vs Kafka vs БДСкачать

  

  СПРОСИ ЭКСПЕРТА: Выпуск 1. Чем отличается шина данных от ETL?Скачать

  

  DATAREON ESB. Коротко о главномСкачать

  

  Шины VS брокеры сообщений | KT.Team | Андрей ПутинСкачать

  

  Способы интеграции системСкачать

  

  Интеграция систем 1С с помощью сервисной шины предприятия DATAREON ESBСкачать

  

  Интеграция 1С с СУБД при помощи сервисной шины данных DATAREON ESBСкачать

  

  Работаем с веб-сервисами из шины данных DATAREON ESBСкачать

  

  Что такое Apache Kafka за 5 минутСкачать

  

  Kafka. Как мы строили корпоративную шину данных, которая обрабатывает до 3 млн сообщ./сек. / И.ГаасСкачать

  

  Корпоративная сервисная шина данных DATAREON ESB. Знакомство с продуктом. Урок 1Скачать

  

  Шина данныхСкачать

  

  Интеграция приложений без ESB | Как ПО становится некрасивым и сложным | Зачем нужен ESBСкачать

  

  Установка и настройка шины DATAREON ESBСкачать

  

  Интеграция AXELOT WMS X5 и 1С:УТ с помощью шины данных DATAREON ESBСкачать