Spring Integration, EIP и Messaging | OTUS
🔥 BLACK FRIDAY!
Максимальная скидка -25% на всё. Успейте начать обучение по самой выгодной цене.
Выбрать курс

Курсы

Программирование
iOS Developer. Basic
-25%
Python Developer. Professional
-25%
Разработчик на Spring Framework
-25%
Golang Developer. Professional
-25%
Python Developer. Basic
-25%
iOS Developer. Professional
-25%
Highload Architect
-25%
JavaScript Developer. Basic
-25%
Kotlin Backend Developer
-25%
JavaScript Developer. Professional
-25%
Android Developer. Basic
-25%
Unity Game Developer. Basic
-25%
Разработчик C#
-25%
Программист С Web-разработчик на Python Алгоритмы и структуры данных Framework Laravel PostgreSQL Reverse-Engineering. Professional CI/CD Vue.js разработчик VOIP инженер Программист 1С Flutter Mobile Developer Супер - интенсив по Kubernetes Symfony Framework Advanced Fullstack JavaScript developer Супер-интенсив "Azure для разработчиков"
Инфраструктура
Мониторинг и логирование: Zabbix, Prometheus, ELK
-25%
DevOps практики и инструменты
-25%
Архитектор сетей
-25%
Инфраструктурная платформа на основе Kubernetes
-25%
Супер-интенсив «IaC Ansible»
-16%
Разработчик программных роботов (RPA) на базе UiPath и PIX
-25%
Супер-интенсив "SQL для анализа данных"
-16%
Базы данных Сетевой инженер AWS для разработчиков Cloud Solution Architecture Разработчик голосовых ассистентов и чат-ботов Внедрение и работа в DevSecOps Администратор Linux. Виртуализация и кластеризация Нереляционные базы данных Супер-практикум по использованию и настройке GIT IoT-разработчик Супер-интенсив «ELK»
Специализации Курсы в разработке Подготовительные курсы
+7 499 938-92-02

Spring Integration, EIP и Messaging

SpringDeep_06.06_Site.png

Spring Integration – очень специфичный проект Spring. По своей сути он содержит в себе реализацию так называемых Enterprise Integration Patterns (EIP) и различные способы их настройки, включая свой собственный Java-DSL.

Чтобы разобраться, что такое Spring Integration и EIP, необходимо понять, какую проблему они решают. Представим, что у нас есть огромное приложение, написанное в классическом стиле Spring с применением IoC-контейнера:

class PersonService {
    // на самом деле куча зависимостей
    private ServiceDependency0 dependency0;
    private ServiceDependency1 dependency1;

    // и параметров конструктора тоже много
    public PersonService(ServiceDependency dependency0, ...) {
        this.dependency0 = dependency0;
    }

    public void processPerson(Person person) {
        // и это далеко не единственные вызовы
        this.dependency0.doOtherProcessing(person);
        this.dependency1.doOtherProcessing(person);
    }
}

Масштабируя этот пример на наше огромное приложение, мы увидим насколько тесно связаны наши классы, даже не смотря на IoC. Действительно, например, мы хотим поменять порядок обработки:

    public void processPerson(Person person) {
        this.dependency1.doOtherProcessing(person);
        this.dependency0.doOtherProcessing(person);
    }
}

Для того, чтобы это сделать, нам необходимо править код сервиса PersonService. А этот метод, в свою очередь, может использовать кто-то другой, для которого очень важен этот порядок. А что, если этот сервис разрабатывает совсем другая организация? А если нам нужно менять поведение динамически, то нужно добавлять условия?

И это далеко не единственные проблемы связанности этих сервисов, и простым способом их не решить.

Что за способ поможет?

Решением может являться так называемый Messaging. Организуем наш код не императивными вызовами методов, а как обработку сообщений, которые ходят по специальным каналам. Тогда наши сервисы будут выглядеть примерно так (в действительности сервис можно не переписывать):

public class ServiceDependencyN {
    // нет смысла делать зависимости от множества сервисов
    // сервис отвечает только за один конкретный шаг
    public ServiceDependencyN() { }

    public Message<Person> processPerson(Message<Person> person) {
        // какой-то шаг обработки
    }
}

Обратите внимание, что метод принимает некое сообщение, содержащее Person, и возвращает новое сообщение. Сервис стал проще, и организовать такой код воедино становится тоже проще. Действительно, нужно просто организовать канал, по которому будут ходить сообщения Message<Person>, проходя все этапы обработки в независимых (!) сервисах.

Но тут возникает несколько вопросов: – А откуда сообщения будут поступать в канал? – А как они будут «выходить» из канала? – Сообщения обрабатываются в отдельных потоках? – Канал представляет собой очередь или что-то вроде topic-а в JMS? – Если очередь, то она с буфером?

Ответом на этот вопросы как раз и служат различные Enterprise Integration Patterns, которые содержат не только большое число различных потоков, но и всевозможные Splitter и Aggregators (позволяющие параллельно обрабатывать batch-и), фильтры, задержки и другие полезные компоненты обработки.

А Spring Integration предназначен для того, чтобы не писать их реализацию самостоятельно и просто интегрировать их в существующее огромное Spring-приложение.

Остались вопросы? Спросите в комментариях!

Не пропустите новые полезные статьи!

Спасибо за подписку!

Мы отправили вам письмо для подтверждения вашего email.
С уважением, OTUS!

Автор
2 комментария
0

ServiceDependency1, ..ServiceDependencyN вместо одного PersonService (в смысле PersonService вообще исчезает)?

0

Как часто приходилось реально использовать или есть информация о применении? По ощущениям, глобально, когда к балу присоединяется camunda и же с ними, то EIP на Spring integration начинает смотреться - чтобы было и чаще свои велосипеды пишут ) буду рад оказаться не правым )

Для комментирования необходимо авторизоваться
🎁 Максимальная скидка!
Черная пятница уже в OTUS! Скидка -25% на всё!