ENG

Сервисная шина предприятия (ESB)

Область применения

Сервисная шина предприятия (англ.enterprise service bus, ESB) — связующее программное обеспечение, обеспечивающее централизованный и унифицированный событийно-ориентированный обмен сообщениями между различными информационными системами на принципах сервис-ориентированной архитектуры.

«Сервисная шина предприятия» является зонтичным термином для набора возможностей, которые в разных реализациях трактуются несколько различными способами. Как правило, выделяются следующие ключевые возможности:

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

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

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

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

Функциональные возможности

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

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

SCA
Эта архитектура основывается на принципе предоставления компонентой своей функциональности в виде сервиса, доступного другим компонентам. В рамках одного модуля компонентами выступают программные блоки (java код), полностью реализующие некий функционал, описанный соответствующим интерфейсом. Логика выполнения компонент реализуется связыванием их в структуру по интерфейсам и reference’ам (Partner Reference).
Такую структуру модуля очень удобно разрабатывать, проверять, развивать, изменять и поддерживать. Атомарность функционала, реализованного в компонентах, позволяет оперировать компонентами в целом, не опускаясь до уровня кода. 

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

Конфигурирование
Через конфигурирование можно настроить некоторые механизмы автоматической реакции на исключительные ситуации (например, автоматическое повторение выполнения компонент при ошибках). Можно «на лету» настроить трассировку компонент или изменить уровни логирования. Также доступен сервис управления сбойными событиями, который можно осознанно настроить много чего использовать для массовой обработки ошибок.
Ну и, конечно же, можно другого согласно спецификации Java2EE

Что мы предлагаем
При интеграции платформы SIEM через компанию Softailor вы получаете:
  • Предпроектное обследование
  • Разработку и проектирование систем
  • Интеграцию и сопряжение с существующей информационной инфраструктурой
  • Инсталляцию и проведение приемо‑сдаточных испытаний
  • Сервисную и техническую поддержку, обеспечивающую оптимальную и бесперебойную работу систем

Наша компания предлагает решения SOA на базе ESB с использованием продуктов:

  • Oracle OCSG
  • 3Scale
  • WSO2 API Manager
  • Api Axle
  • Gravitee
  • ApiMan
  • Kong
  • Tyk
Полный список