This is a DRAFT page for collecting ideas and opinions on possible evolution of DMaaP
Message Router
Current State
DMaaP Message Router utilizes an HTTP REST API to service all Publish and Consume transactions. HTTP and REST standards are followed so clients as varied as CURL, Java applications and even Web Browsers will work to interact with Message Router.
Message Router uses AAF for user’s authentication and authorization.
The MessageRouter service has no requirements on what publishers can put onto a topic. The messages are opaque to the service and are treated as raw bytes. In general, passing JSON messages is preferred, but this is due to higher-level features and related systems, not the MessageRouter broker itself.
Challenges to be addressed
The current message router implementation does not give the receiver control over commits, severely limiting the bus semantics and the performance of the bus.
...
Opportunities to be Investigated
Deployment of Kafka - does adopting a component such as Strimzi add any value in terms of configurability etc?
Security: evolving ONAP towards supporting OAuth 2 natively would allow every component including Kafka to provide authentication. Requires a broader analysis.
Message router API: the principles for having a technology agnostic lightweight message API are good. However these days there are more options in the open source ecosystem which support a broader range of the Kafka semantics - should we consider aligning with one of those:
...
TODO: create a checklist for selection
Native broker API: for low-latency, high volume use cases, how do we securely expose native Kafka APIs?
HV-VES supports reading / writing directly from Kafka: https://docs.onap.org/projects/onap-dcaegen2/en/latest/sections/services/ves-hv/architecture.html
Data Router
Current State
...