Spring Integration, EIP и Messaging

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-приложение.

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