Receiving Connector
Los receiving connectors son responsables de procesar mensajes recibidos en un transport configurado y transformar el mensaje a un tipo conocido, antes de delegar el manejo del mensaje al cliente.
Todos los receiving connectors implementan la interfaz ReceivingConnector, que a su vez extiende OperableConnector.
public interface ReceivingConnector extends OperableConnector {
ReceivingConnectorConfig getConfig();
}
public interface OperableConnector {
/**
* Retrieve name of the connector.
*/
String getName();
/**
* Starts the connector.
*/
void start();
/**
* Starts the connector's health check procedure.
*/
void startHealthCheck();
ConnectorHealth getHealth();
/**
* Shuts down the connector.
*
* @param reason the reason for shutdown
*/
CompletionStage<Void> shutdown(ShutdownReason reason);
/**
* Returns the connector's running status
*/
boolean isRunning();
/**
* Returns the connector's configuration.
*/
ConnectorConfig getConfig();
/**
* Returns all the connector's transports.
*/
List<? extends OperableConnectorTransport> getTransports();
/**
* Abstraction of a connector's configuration.
*/
interface ConnectorConfig {
String getConfigRoot();
}
}Tipo genérico T
La interfaz ReceivingConnector no está acoplada a tipos, aunque la implementación predeterminada ReceiveConnector<T> es genérica con el tipo T, donde T significa 'tipo objetivo'.
Los mensajes recibidos en la capa de transport se pasan al connector envueltos en un objeto TransportMessage y se convierten al tipo objetivo lo antes posible.
Esto permite que etapas posteriores trabajen con un tipo conocido que puede validarse opcionalmente para asegurar la integridad de los datos.
Etapas
La implementación del connector utiliza Akka Streams. Los connectors se componen de varias etapas configurables que se ejecutan de forma asíncrona, donde cada etapa realiza alguna transformación o comprobación para asegurar que los mensajes sean válidos antes de delegar el control de vuelta al cliente para manejar el mensaje recibido.
La imagen siguiente describe de forma aproximada el enfoque basado en etapas al recibir mensajes. Tenga en cuenta que algunas etapas son opcionales y se omitirán si no se configuran cuando se construye el connector.
Las siguientes secciones cubren brevemente cada etapa.
Filtrado
Algunos connector transports como JMS ya tienen funcionalidad para filtrar un mensaje (usando JMS Selectors), pero otros como Kafka o HTTP no. Por esta razón, el Connector framework ofrece una funcionalidad de filtrado.
Para saber cómo filtrar mensajes, vea la documentación de Filtering.
Descifrado del payload
A veces los protocolos de cifrado a nivel de transport, como TLS, no son suficientes. En estos casos se puede aplicar cifrado a nivel de aplicación a los propios mensajes. Al recibir un mensaje cifrado, su payload debe descifrarse antes de que podamos transformarlo al tipo objetivo.
Para saber cómo configurar el descifrado, vea la Encryption.
Conversión a tipo objetivo
El objetivo de un receiving connector es entregar al manejador del cliente un tipo bien definido T.
Para lograrlo, el mensaje recibido de la capa de transport debe convertirse al tipo objetivo.
La transformación ocurre en dos pasos:
-
Convertir el
TransportMessage(del tipo recibido desde el transport, como JSON o bytes) al tipo objetivoT. -
Validar opcionalmente el tipo objetivo, si se configuró un validador de beans.
Para más detalles sobre la conversión, consulte la documentación correspondiente del transport o los convertidores usados.
Asociación de Mensajes
Para solicitudes/respuestas asíncronas, a menudo necesitamos asociar (correlacionar o identificar) mensajes. Si el connector está configurado con un extractor de correlación y un correlation service, el receiving connector intentará relacionar el mensaje con uno enviado previamente.
Para más información, vea la documentación de Message Association.
Validación de Mensajes
Para validar el contenido del mensaje mapeado, puede configurarse un BeanValidator.
Vea la documentación de Message Validation.
Registro de Mensajes
La etapa de logging permite registrar los mensajes recibidos para auditoría o depuración. Vea Message Logging.
Deadletter y manejo de errores
Si ocurre un error en cualquier etapa, el mensaje fallido se pasa a la etapa de manejo de errores. Dependiendo de la configuración, este se anexará a un deadletter y se realizará el acknowledgement según lo requiera el transport.
Para más información, vea Error Handling.