...
| Drawio | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
| Participant Name | Functional purpose | PoC handling |
|---|---|---|
| YANG Model parser | Converts YANG models into java objects | Required |
| YANG Data parser | Converts data compliant with a YANG model into java primitives, assists the CPS core | Required |
| Model store | Keeps a local cache of the structures and relationships (generated from the YANG models) required by the CPS | Required |
| SDC Model loader | Subscribes to DMaaP for CSAR publication. Parses and extracts the models from the CSAR and gives them to the mirror service | Not required |
| Topology sync | Does initial sync and maintains an up to date view of the active topology state. Informs the mirror service of any changes | Not required |
| Mirror service | Encapsulation of all model and data access that relates to xNF | Not required |
| Mirror Data access | REST interface that provides access to xNF data | Not required |
| CPS Core | Provides validation of and access to data. Is agnostic to the DB technology and schema | Required |
| CPS Data access | Provides REST CRUD access to the data | Required |
| CPS notification | Provides a DMaaP notification in the event that (1) data is changed and (2) it has been tagged/marked for notifcation | Required for stretch |
| PostgreSQL plugin | Maps the java primitive representation of the YANG data objects to their DB technology (PostgreSQL) and schema specifics (SQL) | Required |
| PostgreSQL | Database Management System for current data | Required |
| Temporal [Stack] | Placeholder for logical components representing the temporal handling of data | Not required |
| Temporal DB | Database Management System for temporal data | Not required |
Model artifacts
Below a simplified view of model handling artifacts and their relationships.
The run-time artifacts are shaded (orange). A typical simplified flow:
- A document representing xNF data is given to the CPS.
- It will parse (and validate) the document,
- Map data to the generic DB schema and store data.
In order for this to work:
- The document must be compliant to an xNF schema model. This schema model describes the structure of the data and any constraints that need to be checked to ensure integrity.
- The xNF schema model must be written in YANG. This language describes syntax and capabilities (basic concepts).
- A Yang parser is required to interpret documents compliant with the YANG language. The parser is dependent on the language.
- To store data in a DBMS, typically a schema is required. This is denoted above as, 'Generic schema model'.
- Obviously the xNF schema model and the Generic schema model are not the same. Therefor a mapping is required. Depending on how simple/generic/abstract the generic schema model, the mapping may be coupled with either the language or the xNF schema model. One of the aims of the PoC is to be agnostic to the xNF model at run-time, thus the mapping is made to the YANG language.
- To support multiple container run-times (Java, Python, Go, Rust, ...) for the CPS, the mapping is described in a 'Language Capability Map'.
- The model mapper depends on the language capability map and the Yang parser (in particular the java representation of the language features).
Key sequences/flows
Interfaces
Initial draft specification REST & Java
Behavior
Initial sata data structure specification, REST & Java
...