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

Question

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

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

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

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

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

[ Edit : Здесь я имею в виду, что если «B» совместно использует входной и выходной каналы для своего активатора службы, то любой, связанный с выходным каналом «B», получит результат чей-либо запрос на входной канал "B" - и желаемое поведение заключается в том, что ответы направлены на запросчиков.

Я должен отметить, что преобразователь здесь имеет смысл только в контексте Пакета A. Пакет B предоставляет сервис (для всех целей и задач, который я не могу контролировать). Преобразование, специфичное для потребностей Пакета А, должно находиться в Пакете А.] *

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

-

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

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

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

2. Используйте заголовок, чтобы установить REPLY_CHANNEL и передать канал ответа в качестве ссылки, а не значения.

   Этот метод не работал не , элемент заголовка 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>

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

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

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

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

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

Answer 2

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

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

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

Таким образом, в A у вас есть эти компоненты, которые могут использоваться только A:

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

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

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

A зависит от B, но B не зависит от A.

Будет ли это работать?