Project Name:
- Proposed name for the project:
DMaaP – Data and Message Router - Proposed name for the repository:
com.att.dmaap
Project description:
DMaaP Message Router is a reliable, high-volume pub/sub messaging service with a RESTful HTTP API. It is intended to be deployed by Platform Service providers so that it is available to Platform clients as a web service. The service is initially built over Apache Kafka, with some important additional features which focus on integration with other Platform services such as provisioning and authorization.
Scope:
The DMaaP Message Router project will include the following functionality:
- Pub/sub messaging metaphor to broaden data processing opportunities. (refers to the label of the rendezvous point as a “topic”)
- A single solution for most event distribution needs to support a range of environments.
- Packaged to support deployment configurations ranging from a single container to a cluster of hosts.
- Horizontal scalability: Add servers to the cluster to add capacity.
- Durability: Hardware failure in the cluster should not impact service, and messages should never be lost.
- Durability: Consumers should not lose messages if they experience downtime.
- High throughput: Consumers must be able to distribute topic load across multiple hosts in a cluster.
- Easy integration via RESTful HTTP API:
- Implements a RESTful HTTP API for provisioning
- Implements a RESTful HTTP API for message transactions (i.e. pub, sub)
- Implements a RESTful HTTP API for transaction metrics
- Optionally registers with supporting network locations services which will allow client connections to nearest end point. (when there are multiple deployments in a network)
- Client authentication and authorization models:
- Supports multiple authentication and authorization models;
- Default model is “insecure” (i.e. not authenticated)
- Model is associated per topic or per some group of topics.
- Optionally supports a model that relies on external service for client authentication and authorization.
- Optionally supports replication of messages for selected topics to another instance of DMaaP MR.
- Optionally supports different underlying message bus technologies, but makes this transparent to clients.
- Standardized topic names
- Topic registry and discovery
- Recover partially delivered messages from the point of failure
Architecture Alignment:
- How does this project fit into the rest of the ONAP Architecture?
- Please Include architecture diagram if possible
- What other ONAP projects does this project depend on?
- How does this align with external standards/specifications?
- APIs/Interfaces
- Information/data models
- Are there dependencies with other open source projects?
- APIs/Interfaces
- Integration Testing
- etc.
Resources:
- Primary Contact Person - Jack Murray(ATT), Brijesh Khandelwal (Tech Mahendra)
- Names, gerrit IDs, and company affiliations of the committers
- Names and affiliations of any other contributors
- Project Roles (include RACI chart, if applicable)
Other Information:
- link to seed code (if applicable)
- Vendor Neutral
- if the proposal is coming from an existing proprietary codebase, have you ensured that all proprietary trademarks, logos, product names, etc., have been removed?
- Meets Board policy (including IPR)
Use the above information to create a key project facts section on your project page
Key Project Facts
Project Name:
- JIRA project name:
- JIRA project prefix:
Repo name:
Lifecycle State:
Primary Contact:
Project Lead:
mailing list tag [Should match Jira Project Prefix]
Committers:
foo@bar.com
baz@qux.com
*Link to TSC approval:
Link to approval of additional submitters: