Архитектурный принцип Шины в ESB

Введение

Основы ESB

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

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

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

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

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

• Интеграция на основе сообщений
• Абстракция и независимость от конкретных реализаций оконечных точек (end point)
• Гибкость и абстракция от транспортного уровня
• Реализация слабосвязанного взаимодействия (loose coupling)
• Относительная простота подключения новых сервисов (т.е. расширяемость)

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

• Каждый с каждым
• Звезда
• Шина

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

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

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

• Возможность относительно простого подключения большого количества разнообразных сервисов с различными интерфейсами и технологиями интеграции (Web Services, Files, JMS, и т.п.)
• Передача сообщений между сервисами с приемлемой производительностью.
• Возможность маршрутизации сервисов на разных принципах (например на основе заголовков сообщений, на основе типов сообщений, на основе содержащейся в них полезной нагрузке)
• Оркестровка сервисов, в том числе на основе правил
• Конвейерная обработка сообщений (т.е. ситуация в которой сообщения последовательно обрабатываются несколькими сервисами)
• Преобразование сообщений между различными форматами.
• Обеспечение необходимых требований по гарантированности доставки сообщений, при необходимости поддержка транзакционности
• Выполнение требований по производительности и отказоустойчивости
• Управляемость: мониторинг, логирование, возможность подключения и отключения без остановки работы всех сервисов
• Реализация сложных бизнес процессов (Process Choreography)

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

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

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

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

Дата добавления: 2014-01-05