Spring Integration, EIP и Messaging
2026-03-10 18:41 Diff

Теги: java, spring integration, spring framework, enterprise integration patterns, eip, java-dsl, ioc-контейнер, personservice, messaging, message<person>, jms, splitter, aggregators

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

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