Goals
- Replace CORBA with something else the Notification Channel API
Background and strategic fit
This is related to the obsolescence of third-party products that are no longer maintained, or its maintenance is limited.
This also works as a first stone for the study of potential CORBA replacement.
Assumptions
Requirements
| # | Title | User Story | Importance | Notes |
|---|---|---|---|---|
| 1 | API must be available in C++, Java and Python | Developers use those three languages to implement the different parts of ALMA software, therefore the API must be provided in those three languages | Must Have | |
| 2 | The Notification Channel API must hide as much as possible of the underlying technology | The API must be common for all the technologies used to implement this API. This includes CORBA at the beginning | Must have | Notification Channel |
| 3 | The possibility of setting the quality of service and administrative properties of channels must exist. | Each channel has different QoS requirements based on the role they play in whole ALMA system. The user must be able to set this up using the Configuration Database | Must Have | Notification Channel |
| 4 | The API must be implemented in a high-performance manner to reduce the chances of events being discarded, if the QoS settings are set properly. | Each client (publisher or subscriber) must perform accordingly to prevent slow participants. The sending and reception of events should be done as quickly as possible. Each client consuming events from the API is responsible to handle each event timely, otherwise events could be lost. | Must Have | |
| 5 | Notification Channel must decouple publishers from subscribers. | Must Have | ||
| 6 | Notification channel shall deliver events based on best-effort or reliable way. Depending of the QoS configuration. | Must Have | ||
| 7 | Events should be delivered to consumers in a timely manner | The events must be sent and received with the lowest latency possible. Acceptable values are in order of 100 [ms] | Must Have | |
| 8 | Notification channel must support re-connection of clients | If the Event Channel goes down, the Channel must be re-created automatically. All the clients connected to the Event Channel shall reconnect to it. | Must Have | |
| 9 | Notification Channels must provide introspection | The services associated, the channels and the clients must offer operational performance parameters introspection, in a way they can be monitored | Desirable | tickets with problems here |
| 10 | Notification channel should be fault tolerant | Problems in any network path should not affect communications that do not involve that path Events should be queued, up to some limit, in network paths that do have a problem. Data transmission between a publisher and consumer should not require the data be staged in a third place, like a central server. | Must have | |
| 11 | Maintain event order | Events between the same publisher and consumer should be delivered in the same order | Must have |
User interaction and design
Questions
Below is a list of questions to be addressed as a result of this requirements document:
| Question | Outcome |
|---|---|