General Notes

Introduction

In Channel-based binders (i.e., Rabbit, Kafka) Message Conversion is generally handled by pre-configured set of argumentResolvers and MessageConverters used by these argumentResolvers, which typically execute as close as possible to the user's code where the bound type of the target argument is known. See MessageHandlerMethodFactory messageHandlerMethodFactory Bean in BindingServiceConfiguration.

However there is an additional layer where conversion may also happen. This layer is represented by a pair of standard Spring Integration channel interceptors

Inbound:

MessageConverterConfigurer adds InboundContentTypeConvertingInterceptor to the "input" channel.

Primary purpose of this interceptor is to enhance/enrich Message that sent to the inbound (i.e., input) channel with the contentType header for cases where contentType is not present in the Message itself but set on such channel or binder itself via BindingProperties.setContentType(String) (starting v2.0, the default is application/json).

Secondary purpose of this interceptor is to provide backward compatibility with versions of SCSt prior to 2.0 where certain assumption around message conversion were different (specifically the requirement for the originalContentType header in certain cases). See InboundContentTypeConvertingInterceptor.deserializePayload(..) for more details.

Outbound:

MessageConverterConfigurer adds OutboundContentTypeConvertingInterceptor to the "output" channel.

Unlike the inbound conversion which is generally triggered by the knowledge of the target type (e.g., process(Foo foo) - means the payload of the message needs to be converted to Foo). The outbound conversion is triggered primarily by the requirement imposed by the binder (e.g., ensure that Message's payload is converted to byte[]) and is accomplished by the same set of MessageConverters (used by OutboundContentTypeConvertingInterceptor) that will rely on the provided contentType to convert messages.

Similarly to the Inbound, this interceptor also perform additional Message modification to ensure compatibility with Message format prior to version 2.0 and as its inbound counterpart deals with injecting the originalContentType header for certain cases.

NOTE: The originalContentType header is deprecated as of v2.0 and will be removed along with its supporting code in v3.0.

Java/Kryo Serialization

While still supported in the current version of SCSt, Java/Kryo serialization adds additional overhead by requiring Java types to be shared between producers and consumers. Aside form it being and architectural anti-pattern which can lead to hard to track classpath issues, it is not portable across non-java applications while those applications could be easily supported by the middleware used by the available binders such as Kafka and Rabbit. An interoperability could be achieved via simple JSON-based serialization/deserialization.

NOTE: The Java/Kryo Serialization is deprecated as of v2.0 and will be removed along with its supporting code in v3.0.