1. Основы esb

   1. Введение

В программировании под термином ESB (Enterprise Service Bus) понимают определённую архитектурную конструкцию, реализованную, как правило, на основе технологий относящихся к категориям ПО промежуточного слоя (Middleware), предоставляющих базовые сервисы, часто на основе распространённых стандартах на основе событий или сообщений (event or message driven).

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

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

Важно понимать, что ESB не реализует SOA архитектуру, но способен предоставить необходимую инфраструктуру для её построения. В идеале ESB должен основываться на стандартах и поддерживать большое количество различных транспортов и трансформеров.

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

• Интеграция на основе сообщений

• Абстракция и независимость от конкретных реализаций оконечных точек (end point)

• Гибкость и абстракция от транспортного уровня

• Реализация слабосвязанного взаимодействия (loose coupling)

• Относительная простота подключения новых сервисов (т.е. расширяемость)

2. Архитектурный принцип Шины в esb

Термин «шина» в концепции ESB является аналогом компьютерной шины, к которой подключаются различные устройства (например PCI). Как известно существует несколько вариантов подключения устройств, в том числе:

• Каждый с каждым

• Звезда

• Шина

Основным достоинством подключение по топологии Шина является то, что количество связей растёт линейно по отношению к количеству устройств, а в данном случае к количеству сервисов. При этом к шине предъявляется ряд требований:

• Координировать работу устройств (сервисов)

• Обеспечивать передачу сообщений (управляющих сигналов и данных)

• Обеспечивать подключение сервисов.

По этой аналогии типичный ESB должен обеспечивать:

• Возможность относительно простого подключения большого количества разнообразных сервисов с различными интерфейсами и технологиями интеграции (Web Services, Files, JMS, и т.п.)

• Передача сообщений между сервисами с приемлемой производительностью.

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

• Оркестровка сервисов, в том числе на основе правил

• Конвейерная обработка сообщений (т.е. ситуация в которой сообщения последовательно обрабатываются несколькими сервисами)

• Преобразование сообщений между различными форматами.

• Обеспечение необходимых требований по гарантированности доставки сообщений, при необходимости поддержка транзакционности

• Выполнение требований по производительности и отказоустойчивости

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

• Реализация сложных бизнес процессов (Process Choreography)

Основные достоинства подхода ESB:

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

• Большая гибкость

• Основанность на стандартах

• Масштабируемость от примитивной и простой шины до большого распределённого решения для большого количества сервисов и систем

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

• Интеграция осуществляется больше посредством конфигурации а не кодирования

Основные недостатки подхода ESB:

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

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

• Как правило требуются дополнительные аппаратные ресурсы для разворачивания самой инфраструктуры

• Дополнительные требования предъявляемые к персоналу

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