Из чего состоит ESB?

ESB (Enterprise Service Bus) — Компоненты и архитектура

ESB (Enterprise Service Bus) — это **интеграционная платформа для коммуникации между разнородными приложениями** в корпоративной среде. Это набор компонентов и паттернов для маршрутизации, трансформации и управления сообщениями.

Основная идея

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

Традиционный подход (без ESB):
App1 ←→ App2
App1 ←→ App3
App2 ←→ App4
App3 ←→ App4
... (N приложений = N² связей)

С ESB:
App1
App2  ←→ [ESB] ←→ External Systems
App3
App4
(N приложений = N связей на ESB)

Основные компоненты ESB

1. Message Transport (Транспортный слой)

Назначение: доставка сообщений между компонентами системы.

Включает:

• Протоколы: HTTP, JMS, AMQP, TCP/IP, SMTP, FTP
• Механизмы доставки: Synchronous (request-reply), Asynchronous (message queue)
• Очереди сообщений: Хранение сообщений при недоступности получателя

Пример:

Приложение A отправляет сообщение в очередь
     ↓
[Message Queue - хранит сообщение]
     ↓
Приложение B получает сообщение когда готово

2. Message Transformation (Трансформация сообщений)

Назначение: преобразование формата данных между разными системами.

Задачи:

• XML → JSON преобразование
• Изменение структуры данных (flatten, nest структуры)
• Обогащение данных (добавить поля, вычисления)
• Обрезание данных (удалить ненужные поля)
• Валидация формата

Пример:

Приложение Legacy отправляет:
<employee>
  <name>John</name>
  <salary>50000</salary>
</employee>

ESB трансформирует в JSON для Modern API:
{
  "full_name": "John",
  "annual_salary": 50000,
  "currency": "USD"
}

3. Message Routing (Маршрутизация сообщений)

Назначение: направить сообщение нужному получателю на основе правил.

Типы маршрутизации:

Content-based routing (маршрутизация по содержимому)

Если тип="invoice" → отправить в Financial System
Если тип="complaint" → отправить в Support System
Если тип="order" → отправить в Warehouse

Header-based routing (маршрутизация по заголовкам)

Если source=API_v1 → трансформировать и отправить
Если source=legacy → использовать adapter

Rules-based routing (правила)

Если сумма > 10000 → требуется одобрение
Если время работы 9-17 → синхронный вызов
Если время работы 17-9 → асинхронная очередь

4. Message Enhancement / Enrichment

Назначение: добавить информацию к сообщению перед отправкой дальше.

Примеры:

• Добавить ID сессии
• Добавить timestamp
• Добавить информацию о пользователе из БД
• Добавить параметры окружения

Пример:

Приходит сообщение: {order_id: 123}

ESB обогащает его:
- Ищет order в БД
- Добавляет customer_id, amount, status
- Ищет customer в CRM
- Добавляет customer_name, region

Результат: {order_id, order_amount, status, 
customer_id, customer_name, region}

5. Message Validation (Валидация)

Назначение: убедиться что данные соответствуют схеме.

Механизмы:

• Schema validation (XSD для XML, JSON Schema)
• Business rule validation (сумма должна быть > 0)
• Format validation (email, phone format)
• Mandatory fields check

6. Integration Adapters (Адаптеры)

Назначение: связать разнородные системы со своими протоколами.

Типы адаптеров:

• SAP Adapter (для интеграции с SAP)
• Oracle Adapter (для Oracle DB)
• Salesforce Adapter
• File Adapter (для обработки файлов)
• Database Adapter (для прямого доступа к БД)
• Custom Adapters (для legacy систем)

Пример:

Легacy система работает через FTP files
ESB имеет File Adapter который:
1. Читает файл
2. Парсит его
3. Трансформирует в стандартный формат
4. Отправляет в очередь

7. Service Registry / Discovery

Назначение: знать где находятся все сервисы и их API.

Функции:

• Реестр всех доступных сервисов
• Версионирование сервисов
• Информация об interface каждого сервиса
• Service availability и health check

8. Message Monitoring и Logging

Назначение: отслеживать и логировать все сообщения.

Функции:

• Логирование каждого сообщения
• Трейсирование пути сообщения через ESB
• Performance metrics (время обработки)
• Error tracking
• Audit trail (для compliance)

9. Security Components (Безопасность)

Включает:

• Authentication: кто отправляет сообщение?
• Authorization: имеет ли право этот сервис отправлять?
• Encryption: SSL/TLS для передачи
• Message signing: цифровая подпись
• Token-based access control

10. Orchestration Engine (Оркестрация)

Назначение: управление сложными процессами из нескольких сообщений.

Примеры:

Обработка заказа:
1. Получить сообщение о заказе
2. Проверить наличие товара (вызов Warehouse)
3. Если да → создать invoice (вызов Finance)
4. Если нет → отправить notification (вызов Notification)
5. Обновить статус заказа

Оркестрация определяет последовательность вызовов.

Архитектура ESB в целом

┌──────────────────────────────────────────────────┐
│            External Systems / APIs                │
│   (Salesforce, SAP, Legacy, Partners)            │
└────────────────┬───────────────────────────────┘
                 │
           [Integration Adapters]
                 │
        ┌────────┴────────┐
        │                 │
  [File Adapter]  [Web Service Adapter]
        │                 │
┌───────┴─────────────────┴──────────┐
│                                    │
│  ┌──────────────────────────────┐ │
│  │   SERVICE REGISTRY           │ │
│  │  (знает про все сервисы)     │ │
│  └──────────────────────────────┘ │
│                                    │
│  ┌──────────────────────────────┐ │
│  │  MESSAGE ROUTING ENGINE      │ │
│  │  (куда отправить?)           │ │
│  └──────────────────────────────┘ │
│                                    │
│  ┌──────────────────────────────┐ │
│  │  TRANSFORMATION ENGINE       │ │
│  │  (как преобразовать?)        │ │
│  └──────────────────────────────┘ │
│                                    │
│  ┌──────────────────────────────┐ │
│  │  MESSAGE QUEUE / BROKER      │ │
│  │  (хранилище сообщений)       │ │
│  └──────────────────────────────┘ │
│                                    │
│  ┌──────────────────────────────┐ │
│  │  SECURITY / VALIDATION       │ │
│  │  (проверка доступа/формата)  │ │
│  └──────────────────────────────┘ │
│                                    │
│  ┌──────────────────────────────┐ │
│  │  MONITORING / LOGGING        │ │
│  │  (отслеживание)              │ │
│  └──────────────────────────────┘ │
│                                    │
└────────────────────────────────────┘
                 ↓
      [Message Transport Layer]
      (HTTP, JMS, AMQP, etc.)
                 ↓
    ┌────────────┬────────────┐
    │            │            │
 [App 1]    [App 2]       [App 3]

Примеры ESB решений

Open Source:

• Apache ServiceMix — легко, community driven
• Mule ESB — popular, много интеграций
• Apache Kafka — для high-volume data streaming
• RabbitMQ — message broker

Commercial:

• IBM Integration Bus — мощный, enterprise
• Oracle SOA Suite — интеграция с Oracle
• SAP PI/PO — специфично для SAP интеграций
• MuleSoft Anypoint — облачный ESB

Когда использовать ESB?

✅ Используй ESB если:

• Множество приложений которые нужно интегрировать
• Разнородные системы с разными протоколами
• Нужна трансформация данных
• Требуется централизованный мониторинг
• Legacy система + Modern API

❌ Не используй ESB если:

• Всего 2-3 приложения
• Они уже используют одинаковый формат
• Нет требований на трансформацию
• Проект маленький и простой
• Нужна максимальная производительность (ESB может быть узким местом)

Вывод

ESB — это интеграционный каркас который состоит из компонентов для маршрутизации, трансформации, валидации и мониторинга сообщений между приложениями. Это решает проблему "спагетти интеграций" и позволяет управлять сложными межсистемными взаимодействиями централизованно.