...
- As being the event producer, CPS Core is taking ownership of the event schema definition. Also, if the code and the classes to handle the event are not automatically generated, CPS Core could provide them to avoid code duplication. These need to be provided in a separated Maven module, delivered to Nexus and then imported as dependency by subscribers.
- The event publication is CPSDataService responsibility. After its call to DataPersistenceService is completed, it sends a Data Updated Event using a Data Updated Event Producer component. The event contains some DataNode information and JSON Data.
- CPS Core event publications are controlled by a an overall general application sytem environment variable that enable or disable them. By default they are disabled.3 levels of configuration are seen:
- Application overall
- Anchor Yang specific path (using extension ?)
Data Ownership and Access
...
- CPS Temporal querying clients are authenticated and authorized.
- CPS Temporal querying clients only has access to dataspaces and models they own or they have been granted to in CPS Core.
- DMaaP / Kafka event topic is CPS internal, It should be accessible to CPS components only.
Going Further
- Other types of events: Data Deleted, Data Leaf Updated. Support for these types of events within the same schema.
- DMaaP / Kafka authentication and authorization.
- Additional level of filtering to send notifications or not are required on top of the overall general application one:
- Anchor level
- Yang specific path level (using extension ?)
References
...