Issues & decisions
Issue slogan/link | Brief description | Decision |
---|---|---|
Integration pattern for current, historical, temporal, timeseries, etc. | The CPS project proposal covers multiple types of storage. How will it integrate several DBMS technologies to support these different needs? | Option C. Loose coupling. The focus of the PoC will be on current storage and model driven notifications to drive data towards other data stores. |
Interface style | The access interface needs to suit the users of the data. It must also acknowledge the underlying data structure. There are two main options: Providing behavior interfaces on a logical representation of the data; Providing behavior interfaces on the CPS and explicitly providing reference to the data | |
Data Representation | The data that is read from and written to the CPS must comply with a known format. This is relevant to both Java and REST interfaces. The choices here are to provide generic objects/documents, or highly typed (using model info). |
This page summarizes issues (documented in child pages) and the decisions/direction taken.
Decisions/direction is discussed in the child pages, and ratified during the weekly meeting.
Assumptions
Assumption | Reasoning/Justification |
---|---|
The CPS stand-alone access interface technology will be REST | This is common practice in ONAP. There is a drive to harmonize publication and documentation of component interfaces. |
The CPS internal core implementation will be Java | Alternative language bindings will be possible (explicitly enabled by the architecture). The level of resources available indicates that a single implementation should be pursued first. Where other language run-times need access to data they may use the REST data access interfaces. |