Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 27 Next »

WIP


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 Protobuf, Avro or JSON.

Architecture Diagrams

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

(All of them can be seen by navigating thru diagrams tabs using arrows)

Data Updated Event Schema

The structure to represent a Data Updated Event for CPS point of view needs to to be defined without any ambiguity. This the interface contract to be rely on for:

  • CPS Core to publish data updates
  • CPS Temporal to listen to data updates
  • Any other system listening to data updates

Here is an example of a CPS Data Updated Event:

cps-data-updated-event.json
{
  "schema": "urn:cps:org.onap.cps:data-updated-event-schema:1.0.0-SNAPSHOT",
  "id": "38aa6cc6-264d-4ede-b534-18f5c1f403ea",
  "source": "urn:cps:org.onap.cps",
  "type": "org.onap.cps.data-updated-event",
  "correlationId": "7515984f-064a-464f-8849-4c60f886ea4f",
  "content": {
    "timestamp": "2020-12-01T00:00:00.000+0000",
    "dataspaceName": "my-dataspace",
    "schemaSetName": "my-schema-set",
    "anchorName": "my-anchor",
    "data": {
      "interface": {
        "name": "itf-1",
        "status": "up"
      }
    }
  }
}


To be more formal, here is the JSON Schema that is representing any CPS Data Event:

cps-data-updated-event-schema.json
{

  "$schema": "https://json-schema.org/draft/2019-09/schema",
  "$id": "urn:cps:org.onap.cps:data-updated-event-schema:1.0.0-SNAPSHOT",

  "$ref": "#/definitions/CpsDataUpdatedEvent",

  "definitions": {

    "CpsDataUpdatedEvent": {
      "description": "The payload for CPS data updated event.",
      "type": "object",
      "properties": {
        "schema": {
          "description": "The schema, including its version, that this event adheres to.",
          "const": "urn:cps:org.onap.cps:data-updated-event-schema:1.0.0-SNAPSHOT"
        },
        "id": {
          "description": "The unique id identifying the event for the specified source. Producer must ensure that source + id is unique for each distinct event.",
          "type": "string"
        },
        "source": {
          "description": "The source of the event. Producer must ensure that source + id is unique for each distinct event.",
          "type": "string",
          "format": "uri"
        },
        "type": {
          "description": "The type of the event.",
          "type": "string"
        },
        "correlationId": {
          "description": "A unique identifier that may be used to correlate and trace information between several systems.",
          "type": "string"
        },
        "content": {
          "$ref": "#/definitions/Content"
        }
      },
      "required": [
        "schema",
        "id",
        "source",
        "type",
        "content"
      ],
      "additionalProperties": false
    },

    "Content": {
      "description": "The event content.",
      "type": "object",
      "properties": {
        "timestamp": {
          "description": "The timestamp when the data has been observed.",
          "type": "string"
        },
        "dataspaceName": {
          "description": "The name of CPS Core dataspace the data belongs to.",
          "type": "string"
        },
        "schemaSetName": {
          "description": "The name of CPS Core schema set the data adheres to.",
          "type": "string"
        },
        "anchorName": {
          "description": "The name of CPS Core anchor the data is attached to.",
          "type": "string"
        },
        "data": {
          "$ref": "#/definitions/Data"
        }
      },
      "required": [
        "timestamp",
        "dataspaceName",
        "schemaSetName",
        "anchorName",
        "data"
      ],
      "additionalProperties": false
    },

    "Data": {
      "description": "Data as json object.",
      "type": "object"
    }

  }

}


CPS Event API

Having CPS Data Updated Event formalized, we could be able to use at AsyncAPI specification to define CPS Event Driven APIs in similar way we are using OpenAPI to define REST APIs:

asyncapi: 2.0.0
info:
  title: CPS Event API
  version: 1.0.0-SNAPSHOT
  description: This specification describes CPS event driven interfaces.
channels:
  cps/data/updated:
    description:
      This channel is the one on witch CPS Core is publishing notifications when
      its data is updated.
    subscribe:
      message:
        $ref: '#/components/messages/DataUpdated'
components:
  messages:
    DataUpdated:
      payload:
        description: The payload for CPS data updated event.
        type: object
        properties:
          schema:
            description: The schema, including its version, that this event adheres to.
            const: urn:cps:org.onap.cps:data-updated-event-schema:1.0.0-SNAPSHOT
          id:
            description:
              The unique id identifying the event for the specified source.
              Producer must ensure that source + id is unique for each distinct event.
            type: string
          source:
            description:
              The source of the event.
              Producer must ensure that source + id is unique for each distinct event.
            type: string
            format: uri
          type:
            description: The type of the event.
            type: string
          correlationId:
            description:
              A unique identifier that may be used to correlate and trace information
              between several systems.
            type: string
          content:
            type: object
            properties:
              timestamp:
                description: The timestamp when the data has been observed.
                type: string
              dataspaceName:
                description: The name of CPS Core dataspace the data belongs to.
                type: string
              schemaSetName:
                description: The name of CPS Core schema set the data adheres to.
                type: string
              anchorName:
                description: The name of CPS Core anchor the data is attached to.
                type: string
              data:
                description: Data as json object.
                type: object
            required:
              - timestamp
              - dataspaceName
              - schemaSetName
              - anchorName
              - data
            additionalProperties: false
        required:
          - schema
          - id
          - source
          - type
          - content
        additionalProperties: false

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





  • No labels