Весна Интеграция Агрегатор или Маршрутизатор правильный узор?

Question

У меня есть szenario, который кажется на первый взгляд, как идеальная подгонка для использования агрегата для интеграции пружин:

В настоящее время производится большое количество отчетов в формате PDF. Они печатаются через Printrequests в очередь JMS. Сервер печати принимает клиентские сокеты с запросами печати.

Чтобы достичь определенной «справедливости» с точки зрения нагрузки, мы хотели бы объединить запросы на печать для того же принтера. Затем отправьте агрегированные запросы на сервер печати. У нас есть критерии полноты для агрегированных запросов, в основном число pdf, созданных для «Batch», а также уникальный ключ для каждой партии в запрошенных отчетах PDF. Затем агрегированные запросы будут «отправляться» через активатор службы на сервер печати через один и тот же клиентский Socket. Таким образом, в основном мы применяем подход, описанный в Spring Integration Documentation.

Проблема: отчеты начнутся только при печати, когда будет подготовлен последний отчет «Пакет» в формате pdf, который, похоже, создает довольно горлышко бутылки.

В идеале мы можем начать печатать, как только первое сообщение MessageGroup прибывает и эффективно агрегирует результаты запроса на печать.

Я думал добиться этого обычая MessageStore, где метод

public void add(Message<?> messageToAdd) 

реализует дополнительную логику называют сервера печати и на самом деле объединения ответов сервера. Что-то вроде «активного» MessageStore.

Но тогда добавление метода настраиваемого MessageStore может быть «большим» узким местом ... блокирование каждого добавления в «активное» MessageStore ... и также похоже на неправильную метафору: Store vs Processing something.

Является ли Агрегатор правильным подходом для этих требований?

Или я должен идти больше для подхода динамического канала маршрутизатора в проделать описанный Dynamic Ftp Spring Integration Example

С ребенком (ы)/родительским applicationscontext для каждой «Batch» запросов на печати? Там жизненный цикл childs applicationcontext не совсем ясен для меня.

В идеале я бы в состоянии управлять все контексты в - Чайлдс и родителей с JMX, как описано в the Monitoring Example of Spring Integration

Answer 1

Похоже, у вас есть некоторые Buttered cat paradox.

Вы хотите минимизировать нагрузку на сеть посредством агрегированного запроса, но в то же время вы хотите отправить каждый элемент из агрегатора для печати.

Вы должны сами решить, какова ваша цель.

Возможно, вам просто нужен router, какая логика будет основана на некоторых key, чтобы делегировать соответствующий канал для конкретного сокета для отправки на сервер печати?

В противном случае извините: ваша проблема не ясно ...