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