Входящий преобразователь на прокси-шлюзе Spring Integration

Question

Я хотел бы настроить процесс, который выглядит примерно так:

Method Call -> Dynamic Proxy Gateway -> Channel -> Service Activator -> Method Call
             ^---------- Transformer <- Channel <-             [return value]

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

На первый взгляд может показаться, что простым решением является настройка канала ответа по умолчанию на шлюзе. Проблема в том, что я разделяю канал между пакетами с помощью OSGi.Активатор услуги предоставляется Пакетом «Б» и предлагает общий канал для входящих запросов (он действует как сервис поставщика данных).Пакету «А» требуются некоторые данные, поэтому он запрашивает их, но ему нужен результат в альтернативном формате.Обратите внимание: если пакет «B» должен иметь возможность использовать канал ответа по умолчанию, указанный пакетом «A», то пакет «A» должен использовать его.Это всё честно и хорошо, но тогда у меня циклическая зависимость в OSGi, и ничего не запускается.

Кажется, что другим решением здесь было бы определить выходной канал в Service Activator, но здесь возникает немного другая проблема.Предполагая, что я использую выходной канал из пакета «B», я смягчил проблему циклической зависимости, но теперь каждый раз, когда кто-то запрашивает что-то из пакета «A», ответ отправляется всем, кто подключен к выходному каналу — это тоже нежелательно. .

[Редактировать:Я имею в виду, что если «B» использует как входной, так и выходной канал для своего активатора службы, то любой, кто привязан к выходному каналу «B», получит результат любого запроса к входному каналу «B» — и желательное поведение состоит в том, чтобы ответы направлялись запрашивающим сторонам.

Должен отметить, что преобразователь здесь имеет смысл только в контексте Bundle A.Пакет B предоставляет услугу (по сути, ту, которую я не могу контролировать).Преобразование, соответствующее потребностям Пакета А, должно находиться в Пакете А.]

Итак, я думаю, что мне действительно нужно иметь возможность настроить преобразователь для ответов на динамический прокси-шлюз, но как бы я ни старался, я не могу найти такое устройство в руководстве по интеграции Spring.Как всегда, помощь будет принята с благодарностью.

--

Редактировать 2:Здесь я попробовал две другие тактики:

1. Используйте активатор службы, который ссылается на общий канал OSGi из пакета B.

   В результате возвращаемый элемент представлял собой GenericMessageType, который можно было преобразовать.GenericMessageType на самом деле является логическим результатом метода «отправить», на который должен указать активатор службы, а не ответным сообщением.Итак, этот метод делает нет работа.

2. Используйте обогатитель заголовка для установки ОТВЕТ_КАНАЛ и передать канал ответа как ссылку, а не как значение.

   Эта техника сделала нет работает, элемент заголовка REPLY_CHANNEL игнорируется, когда установлен канал ответа по умолчанию шлюза (и канал ответа по умолчанию должен быть установлен).

Answer 1

Теоретически реальный ответ здесь — использовать цепь.

Конфигурация для Bundle A будет выглядеть примерно так:

<si:gateway id="gw" default-request-channel="xyz" />
<si:channel id="xyz" />
<si:chain input-channel="xyz" />
    <si:service-activator />
    <si:transformer />
</si:chain>

Обратите внимание, что для пакета B конфигурация не изменилась, и через OSGi используется только один канал для доступа к пакету A или любым третичным пакетам.

Доступны два варианта услуги-активатора:

1. Общий сервис через OSGi
2. Пользовательская служба, которая просто вызывает прокси-шлюз для возвращаемого типа данных перед преобразованием.

Прокси-шлюз в пакете A будет вводить в некоторый входной канал «xyz», и в конечном итоге подразумеваемый обратный канал будет содержать преобразованный контент по желанию.

Это решение почти такое же, как решение, предложенное SingleShot, однако здесь мы предотвращаем совместное использование реального сервиса через OSGi, сохраняя границы пакета.

Answer 2

Меня немного смутило ваше описание проблемы.Я понимаю аспект циклической зависимости и аспект преобразователя, но я не уверен насчет того, что «ответ отправляется всем, кто подключен к A».

Похоже, вам может понадобиться два активатора службы для B.Ваш существующий вариант в B останется, и большинство клиентов будут его использовать.Другой будет входить в A и будет использовать только каналы, определенные в A.Это не позволит запросам от A к B привести к получению ответов компонентами за пределами A.

Это должно облегчить задачу трансформации.Трансформаторы берут сообщение из одного канала, преобразуют его и помещают в другой.Просто добавьте один в A, и все будет хорошо.

Итак, в A у вас будут следующие компоненты, которые может использовать только A:

• шлюз
• входной канал
• активатор услуги для B
• выходной канал
• трансформатор
• преобразованный выходной канал

В B вы бы могли использовать любой:

• входной канал
• активатор услуги для B
• выходной канал

А зависит от Б, но Б не зависит от А.

Это сработает?