I am looking at this KNative Eventing architecture diagram
And notice that the colour of arrows that goes into custom services is blue, that is the Services can only get called via HTTP protocol.
HTTP protocol is synchronous and also request/response oriented.
That seems to be contradiction to the Eventing nature, where we should aim at designing systems that are subscribe/notify oriented and asynchronous instead.
The source for the Service messages on the diagram is Kafka. That is a message broker whose primary purpose is to support asynchronous message delivery and subscribe/notify cases.
Why would KNative Eventing change that original channel transport nature from asynchronous subscribe/notify to synchronous request/response calling the services.
Is that true that the Services may only be called via HTTP in KNative Eventing (without custom work for developing own sidecars and service wrappers)? That looks to be a significant limitation.
If yes, why is that so? Is that done intentionally, or is it a temporary solution. Why can't Service consume from channel (e.g. backed by Kafka) directly and why "channel subscriber" cannot be built into the Service Docker image wrapper or a sidecar.
