Transformador de entrada en Spring Integration Proxy Gateway

Question

Me gustaría configurar un proceso que se parezca a:

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

Efectivamente, me gustaría acceder de alguna manera al canal oculto que Spring Integration crea y transformar la carga útil del mensaje de retorno en un tipo de mensaje diferente.

Al principio, puede parecer que una solución simple es configurar un canal de respuesta predeterminado en la puerta de enlace, el problema es que estoy compartiendo el canal entre paquetes usando OSGi. El activador de servicio es proporcionado por Bundle " B " ;, y ofrece un canal compartido para las solicitudes entrantes (actúa como un servicio de proveedor de datos). Paquete " A " requiere algunos datos, por lo que lo solicita, pero necesita el resultado en un formato alternativo. Tenga en cuenta que si Bundle " B " debían poder utilizar el canal de respuesta predeterminado especificado por Bundle " A " luego Bundle " A " debe compartirlo Eso es justo y bueno, pero tengo una dependencia circular en OSGi y nada comenzaría.

Parece que otra solución aquí sería definir un canal de salida en el Activador de servicio, pero esto tiene un problema ligeramente diferente. Suponiendo que comparto el canal de salida de Bundle " B " He mitigado el problema de la dependencia circular, pero ahora cada vez que alguien solicita algo a Bundle " A " la respuesta va a todos los que están conectados al canal de salida; esto tampoco es deseable.

[ Editar : lo que quiero decir aquí es que si " B " comparte un canal de entrada y un canal de salida para su activador de servicio, entonces cualquier persona vinculada al canal de salida de B recibirá el resultado de la solicitud de cualquiera al canal de entrada de B, y el comportamiento deseado es que las respuestas se dirigen a los solicitantes.

Debo señalar que el transformador aquí tiene sentido solo en el contexto del Paquete A. El Paquete B proporciona un servicio (para todos los efectos y sobre los que no tengo control). La transformación, específica a las necesidades del paquete A, debe residir en el paquete A.]

Entonces, lo que creo que realmente necesito es poder configurar un transformador en las respuestas a una puerta de enlace proxy dinámica, pero lo intento como puedo, no puedo encontrar ese dispositivo en el manual de Spring Integration. Como siempre, la ayuda sería muy apreciada.

-

Editar 2 : Intenté otras dos tácticas aquí:

1. Utilice un activador de servicio que se refiera al canal compartido OSGi del Paquete B

   El resultado fue que el elemento devuelto era un GenericMessageType, que podría transformarse. GenericMessageType es realmente el resultado booleano de "enviar" método al que debe apuntar el activador del servicio, no el mensaje de respuesta. Entonces este método no funciona.

2. Utilice un enriquecedor de encabezado para establecer REPLY_CHANNEL y pasa el canal de respuesta como referencia en lugar de como valor.

   Esta técnica no funcionó no , el elemento de encabezado REPLY_CHANNEL parece ignorarse cuando se establece el canal de respuesta predeterminado de la puerta de enlace (y el canal de respuesta predeterminado debe be set).

Answer 1

En teoría, la verdadera respuesta aquí es usar una cadena.

La configuración para el paquete A se parecerá 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>

Nota para el paquete B: la configuración no cambia y solo un canal único se comparte a través de OSGi para el acceso del paquete A o cualquier paquete terciario.

Hay dos opciones disponibles para el activador del servicio:

1. Servicio compartido a través de OSGi
2. Servicio personalizado que simplemente invoca una puerta de enlace proxy para el tipo de datos devuelto previo a la transformación.

El proxy-gateway en el Paquete A se inyectará en algún canal de entrada '' xyz '' y, en última instancia, el canal de retorno implícito contendrá el contenido transformado como se desee.

Esta solución es casi la misma que la propuesta por SingleShot, sin embargo, aquí evitamos compartir un servicio real a través de OSGi, manteniendo los límites del paquete.

Answer 2

Estoy un poco confundido por la descripción de tu problema. Entiendo el aspecto de la dependencia circular y el aspecto del transformador, pero no estoy tan seguro acerca de "la respuesta va a todos los adjuntos a A".

Suena como si quisiera tener dos activadores de servicio para B. Su actual en B se quedaría, y la mayoría de los clientes lo usarían. El otro iría en A, y solo usaría los canales definidos en A. Esto evitaría que las solicitudes de A a B provoquen que las respuestas sean recibidas por componentes fuera de A.

Esto debería facilitar el problema de la transformación. Los transformadores toman un mensaje de un canal, lo transforman y lo colocan en otro. Simplemente agregue uno en A y debería ser bueno.

Entonces, en A, tendría estos componentes, solo utilizables por A:

• una puerta de enlace
• un canal de entrada
• un activador de servicio para B
• un canal de salida
• un transformador
• un canal de salida transformado

En B tendrías, utilizable por cualquiera:

• un canal de entrada
• un activador de servicio para B
• un canal de salida

A depende de B, pero B no depende de A.

¿Funcionará eso?