Page Comparison

...

Introduction

• CPS Temporal is a dedicated service, distinct and decoupled from CPS Core (separated option #4 from CPS-78: Deployment View).
• Integration between Core and Temporal is event notification based, asynchronous, send and forget. By doing this, we are avoiding the dependency from CPS Core on CPS Temporal and its API. Actually, it reverses the dependency, which makes more sense from a conceptual point of view.
• For each data modification handled by CPS Core,
  • CPS Core is publishing, to a dedicated topic, an event representing the data configuration or state.
  • CPS Temporal is listening to the same topic for the event and is responsible to keep track of all data over time.
  • In the future, some other services can be created to listen to the same topic in order to implement additional functionalities or storage forms.
• The event messaging system for this integration is either DMAAP or Kafka (to be deployed independently of CPS). The choice between one of the two is made by configuration when deploying CPS services.
• Events published by CPS Core contains following information:
  • Timestamp
  • Dataspace
  • Schema set
  • Anchor
  • Data (complete json data payload)
• A contract is defined to make the expected information explicit for the publisher and all subscribers. This contract can be provided by a structured event schema format using JSON, Protobuf or Avro.

...

...

As current producer and consumer are part of the same team, the proposition is to start with JSON Text format and put in place a reliable process to manage and use the schema within the team.

Going Further

...

CPS Core Changes

• 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 an overall general application sytem environment variable that enable or disable them. By default they are disabled.

Data Ownership and Access

CPS Temporal is part of and internal to overall CPS system.

CPS Temporal service is following CPS data ownership and access rules:

• 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 system internal, It should be accessible to CPS components only.

Going Further

• Other types of events: Data Deleted, Data Leaf Updated (partial node). Support for these types of events within the same schema.
• Additional levels of filtering to send notifications or not are seen on top of the overall general application one:
  • Anchor level
  • Yang specific path level (using extension ?)
• DMaaP / Kafka authentication and authorization.
• Timestamp format on the event (ISO)

References

• CPS-78: Deployment View
• CPS Internal Relation DB Schema
• JSON Schema
• AsyncAPI
• Protocol Buffers
• Apache Avro