Project: springxd
Issue XD-701: Refactor Message conversion in ChannelRegistrySupport
After an initial attempt which was not ready for M2 we are rethinking our strategy. One of the fundamental things we have come to realize is that its important to treat serialization and type conversion as separate concerns. Serialization: A core principle is the consumer should by default receive exactly what the producer sent: - If the producer sends a byte[] payload then no serialization is required. - A String payload can use simple byte conversion, taking the Charset into account - Transporting an Object uses whatever serialization is configured (json, xml, avro, protocol buffer, java.io, msgpack, etc.). The actual serialization performed for each message must be shared with the producer and consumer. I.e., the consumer needs to know which case above applies to each payload. Currently we are using the MessageHeaders.CONTENT_TYPE defining custom mime types for this (The designated header is subject to change) Conversion: - The consumer optionally defines one or more content-types (read MimeType) it can accept in order of preference. If no conversion succeeds, we can either give them the byte[] payload or throw an exception (configurable?). Examples: - Consumer accepts a Java Object (application/x-java-object;type=example.Foo). Assume for simplicity, the consumer may send a JSON String, or a Foo. On the receiving end we need to distinguish a String payload containing a JSON representation of Foo from a serialized Foo payload. If the payload is a String, we need to know that its original content is application/json. We are currently using a 2nd "original-content-type" message header to supply this information. So in the first case we have (conceptually) content-type: "XD plain text" , original-content-type "application/json". In the second case we have content-type: "XD Serialized JSON" original-content-type not used in this case since the serialized JSON includes type information (using Jackson conventions which are a bit brittle). -If the producer type is different from the accepted type, we use the conversion service and the consumer must register appropriate converters. A twist for XD that may be generally relevant is that some optimization is possible when we know the bytes represent JSON: - Tuple conversion: Since we serialize using JSON and we know how to transform JSON <->Tuple, we can convert any Object payload or any JSON String to a Tuple. We can avoid the two step deserialization+conversion, e.g. 1) Foo->JSON->Foo 2) Foo->Tuple.
Story points: 10