...

...

...

...

...

...

...

...

...

...

This is a DRAFT page for collecting ideas and opinions on possible evolution of DMaaP

Byung-Woo Jun, Fiachra Corcoran

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.

...

The message router exposes a subset of the Kafka semantics and has a client aware architecture relying on zookeeper to “move” a Kafka adapter related to a consumer from one server to another. It does not support acknowledges - messages are acknowledged upon successful reply to a GET. If a client crashes straight after receiving a reply at least once semantics are broken. This makes message router in its current form unsuitable for mission critical data and control flows.

Opportunities to be Investigated

Deployment of Kafka - does adopting a component such as Strimzi add any value in terms of configurability etc?

...

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

...

Challenges to be addressed

Opportunities to be investigated

Integration with external storage systems

...