add Message Service Requirements #4
Conversation
Signed-off-by: Steve Taylor <[email protected]>
|
To be consistent, what name should be used, Message Service, Message Broker, Event Service, Event Broker etc? |
Good question, since in CDEvents we talk about "Events", perhaps "Event Broker" is a good option? |
There was a problem hiding this comment.
@sbtaylor15 - Thanks for the PR! I think we need to add some diagrams and more granularity on how the message bus is going to work in the overall CDEvents ecosystem.
Right now it doesn't really show that and more so talks about technologies, which is great, but we still need to expand on the technical implementation portions.
We need to illustrate what the message bus will look like. This can be as simple as another message bus service like kafka. We need to show how interacting with the different bus example would look. What would sending and receiving events look like from a code stance?
We can start with this diagram and expand on it.
|
|
||
| ## **1\. Introduction** | ||
|
|
||
| The purpose of this document is to outline the requirements for implementing a CDEvents message service for all open-source projects. This service will be based on CDEvents and **WILL** run in an environment that will utilize the CDEvents message service. The message service **WILL** utilize any supported protocols of CloudEvents and will incorporate security measures to prevent attacks. |
There was a problem hiding this comment.
This service will be based on CDEvents and WILL run in an environment that will utilize the CDEvents message service.
This reads odd.
This service, this is the CDEvents message service, but then we go on to say it will run in an environment that utilize the CDEvents message service. "WILL run", this is the message bus?
There was a problem hiding this comment.
This sentence may need to be rewritten some too
The message service WILL utilize any supported protocols of CloudEvents and will incorporate security measures to prevent attacks.
Maybe something like
The message service WILL be designed with security's best practices in mind and support any protocols that CloudEvents supports.
|
|
||
| The purpose of this document is to outline the requirements for implementing a CDEvents message service for all open-source projects. This service will be based on CDEvents and **WILL** run in an environment that will utilize the CDEvents message service. The message service **WILL** utilize any supported protocols of CloudEvents and will incorporate security measures to prevent attacks. | ||
|
|
||
| This document covers the requirements for developing, and deploying a CDEvents message service. It includes functional and non-functional requirements, security measures, and constraints of the overall environment. |
There was a problem hiding this comment.
| This document covers the requirements for developing, and deploying a CDEvents message service. It includes functional and non-functional requirements, security measures, and constraints of the overall environment. | |
| This document covers the requirements for developing and deploying a CDEvents message service. It includes functional and non-functional requirements, security measures, and constraints of the overall environment. |
|
|
||
| ### **2.1 Product Perspective** | ||
|
|
||
| The CDEvents message service is an integral component of the CI/CD pipeline for open-source projects. It will facilitate event-driven communication across different stages of the development lifecycle, ensuring seamless integration and automation. |
There was a problem hiding this comment.
| The CDEvents message service is an integral component of the CI/CD pipeline for open-source projects. It will facilitate event-driven communication across different stages of the development lifecycle, ensuring seamless integration and automation. | |
| The CDEvents message service is an integral component of the software development lifecycle (SDLC) for open-source projects. It will facilitate event-driven communication across different stages of the SDLC, ensuring seamless integration and automation. |
|
|
||
| ### **4.1 Use Case Diagrams** | ||
|
|
||
| \[Include use case diagrams illustrating the interactions between actors and the system.\] |
There was a problem hiding this comment.
We probably should add a few diagrams to help illustrate the proposal
|
If it helps please feel free to take inspiration from https://eiffel-community.github.io/eiffel-sepia/ and let us know your thoughts about it. |
Cleaned up and converted the Google doc to markdown.
Signed-off-by: Steve Taylor [email protected]