0 added
0 removed
Original
2026-01-01
Modified
2026-03-10
1
<p>Теги: java, spring integration, spring framework, enterprise integration patterns, eip, java-dsl, ioc-контейнер, personservice, messaging, message<person>, jms, splitter, aggregators</p>
1
<p>Теги: java, spring integration, spring framework, enterprise integration patterns, eip, java-dsl, ioc-контейнер, personservice, messaging, message<person>, jms, splitter, aggregators</p>
2
<p>Spring Integration - очень специфичный проект Spring. По своей сути он содержит в себе реализацию так называемых<strong>Enterprise Integration Patterns</strong>(EIP) и различные способы их настройки, включая свой собственный<strong>Java-DSL</strong>.</p>
2
<p>Spring Integration - очень специфичный проект Spring. По своей сути он содержит в себе реализацию так называемых<strong>Enterprise Integration Patterns</strong>(EIP) и различные способы их настройки, включая свой собственный<strong>Java-DSL</strong>.</p>
3
<p>Чтобы разобраться, что такое Spring Integration и EIP, необходимо понять, какую проблему они решают. Представим, что у нас есть огромное приложение, написанное в классическом стиле Spring с применением IoC-контейнера:</p>
3
<p>Чтобы разобраться, что такое Spring Integration и EIP, необходимо понять, какую проблему они решают. Представим, что у нас есть огромное приложение, написанное в классическом стиле Spring с применением IoC-контейнера:</p>
4
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); } }<p>Масштабируя этот пример на наше огромное приложение, мы увидим насколько тесно связаны наши классы, даже не смотря на IoC. Действительно, например, мы хотим поменять порядок обработки:</p>
4
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); } }<p>Масштабируя этот пример на наше огромное приложение, мы увидим насколько тесно связаны наши классы, даже не смотря на IoC. Действительно, например, мы хотим поменять порядок обработки:</p>
5
public void processPerson(Person person) { this.dependency1.doOtherProcessing(person); this.dependency0.doOtherProcessing(person); } }<p>Для того, чтобы это сделать, нам необходимо править код сервиса<strong>PersonService</strong>. А этот метод, в свою очередь, может использовать кто-то другой, для которого очень важен этот порядок. А что, если этот сервис разрабатывает совсем другая организация? А если нам нужно менять поведение динамически, то нужно добавлять условия?</p>
5
public void processPerson(Person person) { this.dependency1.doOtherProcessing(person); this.dependency0.doOtherProcessing(person); } }<p>Для того, чтобы это сделать, нам необходимо править код сервиса<strong>PersonService</strong>. А этот метод, в свою очередь, может использовать кто-то другой, для которого очень важен этот порядок. А что, если этот сервис разрабатывает совсем другая организация? А если нам нужно менять поведение динамически, то нужно добавлять условия?</p>
6
<p>И это далеко не единственные проблемы связанности этих сервисов, и простым способом их не решить.</p>
6
<p>И это далеко не единственные проблемы связанности этих сервисов, и простым способом их не решить.</p>
7
<h2>Что за способ поможет?</h2>
7
<h2>Что за способ поможет?</h2>
8
<p>Решением может являться так называемый Messaging. Организуем наш код не императивными вызовами методов, а как обработку сообщений, которые ходят по специальным каналам. Тогда наши сервисы будут выглядеть примерно так (в действительности сервис можно не переписывать):</p>
8
<p>Решением может являться так называемый Messaging. Организуем наш код не императивными вызовами методов, а как обработку сообщений, которые ходят по специальным каналам. Тогда наши сервисы будут выглядеть примерно так (в действительности сервис можно не переписывать):</p>
9
public class ServiceDependencyN { // нет смысла делать зависимости от множества сервисов // сервис отвечает только за один конкретный шаг public ServiceDependencyN() { } public Message<Person> processPerson(Message<Person> person) { // какой-то шаг обработки } }<p>Обратите внимание, что метод принимает некое сообщение, содержащее<strong>Person</strong>, и возвращает новое сообщение. Сервис стал проще, и организовать такой код воедино становится тоже проще. Действительно, нужно просто организовать канал, по которому будут ходить сообщения<em>Message<Person></em>, проходя все этапы обработки в независимых (!) сервисах.</p>
9
public class ServiceDependencyN { // нет смысла делать зависимости от множества сервисов // сервис отвечает только за один конкретный шаг public ServiceDependencyN() { } public Message<Person> processPerson(Message<Person> person) { // какой-то шаг обработки } }<p>Обратите внимание, что метод принимает некое сообщение, содержащее<strong>Person</strong>, и возвращает новое сообщение. Сервис стал проще, и организовать такой код воедино становится тоже проще. Действительно, нужно просто организовать канал, по которому будут ходить сообщения<em>Message<Person></em>, проходя все этапы обработки в независимых (!) сервисах.</p>
10
<p><strong>Но тут возникает несколько вопросов:</strong>- А откуда сообщения будут поступать в канал? - А как они будут "выходить" из канала? - Сообщения обрабатываются в отдельных потоках? - Канал представляет собой очередь или что-то вроде topic-а в JMS? - Если очередь, то она с буфером?</p>
10
<p><strong>Но тут возникает несколько вопросов:</strong>- А откуда сообщения будут поступать в канал? - А как они будут "выходить" из канала? - Сообщения обрабатываются в отдельных потоках? - Канал представляет собой очередь или что-то вроде topic-а в JMS? - Если очередь, то она с буфером?</p>
11
<p>Ответом на этот вопросы как раз и служат различные<strong>Enterprise Integration Patterns</strong>, которые содержат не только большое число различных потоков, но и всевозможные<strong>Splitter</strong>и<strong>Aggregators</strong>(позволяющие параллельно обрабатывать<strong>batch-и</strong>), фильтры, задержки и другие полезные компоненты обработки.</p>
11
<p>Ответом на этот вопросы как раз и служат различные<strong>Enterprise Integration Patterns</strong>, которые содержат не только большое число различных потоков, но и всевозможные<strong>Splitter</strong>и<strong>Aggregators</strong>(позволяющие параллельно обрабатывать<strong>batch-и</strong>), фильтры, задержки и другие полезные компоненты обработки.</p>
12
<p>А<strong>Spring Integration</strong>предназначен для того, чтобы не писать их реализацию самостоятельно и просто интегрировать их в существующее огромное Spring-приложение.</p>
12
<p>А<strong>Spring Integration</strong>предназначен для того, чтобы не писать их реализацию самостоятельно и просто интегрировать их в существующее огромное Spring-приложение.</p>
13
<p><em>Остались вопросы? Спросите в комментариях!</em></p>
13
<p><em>Остались вопросы? Спросите в комментариях!</em></p>
14
14