Versions Compared

Old Version 27

changes.mady.by.user Former user

Saved on

compared with

New Version 28

changes.mady.by.user Former user

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Warning
titleWIP


Table of Contents

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 or JSON.

Architecture Diagrams

Following diagrams are C4 model diagrams (context, containers and components) for CPS Temporal.

...

AsyncAPI Playground can be used to visualize the specification. To go furtherThen, it could be worth looking at documentation and code generation features.

Binary Format Alternatives

Instead of JSON, another option to exchange event over the network would be to use a serialized binary format such as Protocol Buffers or Apache Avro.

Option 1: Plain JSON Text

(plus) Observing message data is straightforward.

(plus) No additional step to serialize and de-serialize data.

(minus) If the code and classes to handle the event is not generated, either it needs to be provided or it will be left to producers and consumers responsibility.

Option 2: Binary

(plus) Producers and consumers benefit from code generation tools to handle event data. This is efficient and reliable for consistency between producers and consumers.

(plus) Binary formats are optimized for payload size and efficient for network transport (might not be relevant for CPS as most of the data payload belongs to an unique field).

(minus) Additional step to serialize and de-serialize data.

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

  • How and where the event schema or API is managed (source control, version, deliver, publish, consumption, ...) ?
  • How and where the code handling events is managed if not generated ?

References