As Axon Framework matured, we have had doubts about the current approach and placement of the Serializer.
Serializing and deserializing Messages is tightly nit to the ContentTypeConverters within the Framework and is an integral part of what you would expect from a message-driven framework.
However, adjusting the Serializer to a more generic Converter would greatly increase the interface's use cases.
If we think about it, all Axon Framework does with messages, is convert them from one type to another.
As stated earlier, that is what the Serializer implementations do.
They use the existing ContentTypeConverter to jump from concrete type, to Document (for XML) or JsonNode (for Jackson), and then further to String or byte[]. And, vice versa.
Having these steps is what makes the Upcasters work as well.
If we could move the content type conversion behavior to become a first-class citizen, we would gain a number of benefits:
The concept more closely aligns with what Axon Framework actually is doing.
We would have a great stepping stone to allow Message-Handlers to handle whatever type they want. For example, the Message Handler could define the QualifiedName of the message it wants to handle (as introduced in #3085) and handle it as a concrete-class/String/JsonNode/Map<String, Object>/etc. Doing this would eliminate the tight coupling on the concrete classes, opening up message handlers to handle everything the user would desire.
We would be able to replace Upcasters for a specific type of Converter. This would make upcasting a lot easier for other types of components.
Since the Serializer is tightly woven throughout Axon Framework, this change will have quite some impact.
Hence when working on this, it is recommended to first draft the desired Converter API and validate its use.
Once that process has finalized, we should be able to integrate the Converters throughout Axon Framework's infrastructure components.
Lastly, we should drop the default XStreamSerializer/XStreamConverter, due to the disadvantages XStream faces with its heavy reliance on reflection. Instead, users should be required to select the Converter of choice at all times.
As Axon Framework matured, we have had doubts about the current approach and placement of the
Serializer. Serializing and deserializingMessagesis tightly nit to theContentTypeConverterswithin the Framework and is an integral part of what you would expect from a message-driven framework.However, adjusting the
Serializerto a more genericConverterwould greatly increase the interface's use cases. If we think about it, all Axon Framework does with messages, is convert them from one type to another.As stated earlier, that is what the
Serializerimplementations do. They use the existingContentTypeConverterto jump from concrete type, toDocument(for XML) orJsonNode(for Jackson), and then further toStringorbyte[]. And, vice versa. Having these steps is what makes the Upcasters work as well.If we could move the content type conversion behavior to become a first-class citizen, we would gain a number of benefits:
QualifiedNameof the message it wants to handle (as introduced in #3085) and handle it as a concrete-class/String/JsonNode/Map<String, Object>/etc. Doing this would eliminate the tight coupling on the concrete classes, opening up message handlers to handle everything the user would desire.Converter. This would make upcasting a lot easier for other types of components.Since the
Serializeris tightly woven throughout Axon Framework, this change will have quite some impact. Hence when working on this, it is recommended to first draft the desiredConverterAPI and validate its use. Once that process has finalized, we should be able to integrate theConvertersthroughout Axon Framework's infrastructure components.Lastly, we should drop the default
XStreamSerializer/XStreamConverter, due to the disadvantages XStream faces with its heavy reliance on reflection. Instead, users should be required to select theConverterof choice at all times.