Internal remoting layer re-implementation

[andybritz]

The initial remoting layer was done just as a POC, we do need to do this properly and need to consider things in terms of performance, security etc.

This is just a holder for a full proposal on the remoting. This could potentially be generalised to provide an inter-node remoting layer for any Kafka Streams cluster.

[szoio]

The existing method requires that the client participates as a node in the Simple Sourcing app. It doesn't allow a separation where a Simple Sourcing app does Simple Sourcing and nothing else, and another app, such as a web service, calls into it, without taking on any additional burden.

Here is an alternative mechanism:

1. Each instance of the Simple Sourcing client creates a topic for command responses that’s unique to that client. Includes the IP address / hostname in the topic name. Call it command-response-hostname.
2. A shared response topic name mapping topic is created. This has key=command ID, value=topic name. Call it response_mapping. This can be shared across all clients, and even across all aggregates.
3. Each time a client submits a command request, it writes a record in the response_mapping topic. This will be a record (k,v)=(UUID, command-response-hostname)
4. When the simple source API generates a response, it goes into command_response table.
5. A join is made of the command_response and response_mapping streams is made by the command ID. The result of this join is written into the topic pointed to by response_mapping. This can be done since Kafka 2.0 (https://cwiki.apache.org/confluence/display/KAFKA/KIP-303%3A+Add+Dynamic+Routing+in+Streams+Sink), using the KStream method void to​(TopicNameExtractor<K,V> topicExtractor, Produced<K,V> produced)
6. The client creates a consumer that listens to the command-response-hostname topic. It will be the only consumer listening to this topic, and only responses that for requests it submitted will arrive in this topic.

The only downside is that a lot of topics get created (one per client, though they can be shared across aggregate as CommandResponse is generic). It doesn’t seem like Kafka streams is particularly parsimonious in this regard, when you look at how many topics kafka streams creates! This could also be considered a positive, as it also provides a record of client usage.

[szoio]

Address and merged in: https://github.com/simplesourcing/simplesource/pull/18