Hi Ali, thanks for the additional context. I thought I’d responded but our community board software seems to have eaten it, so let’s try again and my apologies for the delay:
-
FLOWS: FlowReceivers are a PERSISTENT messaging concept; they only apply to persistent endpoints that save messages for you until you consume and acknowledge them
-
CACHES: Cache requests are a DIRECT messaging concept; they do not work with persistence so cache results cannot come through your queue consumers
I don’t think topic-dispatch would have helped you to unify those two flows because of this.
For type-dispatching, ideally you would have publishers pub a unique schemaID on published messages that consumers could use to dispatch to proper deserializers, etc. The advantage to this is that it would work in any handler, and you could even factor out that dispatch capability into its own component if you wanted.
This could be in a user-defined property. See TomF’s blog post about using header properties. Or there is a 36-byte binary msg-field called UserData that you can access via getters/setters. It could even be the first few bytes of your payload, although the disadvantage of this is that you always need to extract the payload to find the schema type, even if your app would discard messages of schemas it didn’t want.
The question for you is – can you mandate publishers put a schemaID on their messages identifying the payloads? Or is this outside of your control?