| Table of Contents |
|---|
Current View
| Excerpt | |||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
The following diagram represents CPS development view for components implemented in the PoC.
|
Service Data Registry, State, xNF Proxy components will need to be added to enrich the diagram and show where they are running (pod, container, application server)
Alternative deployment options
One of the purposes of having both Java and REST interfaces is to enable flexibility in deployment.
It has not been decided which deployments will be supported — yet!
The deployment flavors are not mutually exclusive.
The JDBC parameters need to be configurable — right now we do not know if CPS will use an existing DBMS or a dedicated instance. Going forward, it may be that different instances require (for security purposes) dedicated instances of the DBMS. It may also be that different instances need to share access to the same DBMS (say for horizontal scale)
I can see no good reason to have multiple JDBC connections when we introduce the CPS NF Proxy functionality.
Bundling/coupling the build (the creation of the image) in the cps-rest does not work for this level of flexibility — several different (µS image) build instructions are needed.
I do not get the 1:1 relationship between the SpringBootApplication and the REST interface above. If the code is in separate SpringBootApplications, what is the invocation overhead introduced by Spring to resolve the implementation of an interface?
- Standalone
- Scenario: Need to store non-NF data
- Basic YANG data storage
- CPS NF Proxy
- Scenario: Need to access NF CM data quickly (cache) and also store application data (E2E network slicing)
- Basic YANG data storage
- NF CM data storage (requires co-deployment to avoid communication (serialization/de-serialization) overhead
- CPS NF Proxy, Temporal
- Scenario: The temporal stack is interested in NF CM data
- Basic YANG data storage
- NF CM data storage (requires co-deployment to avoid communication (serialization/de-serialization) overhead
- Temporal data storage/access (requires co-deployment to avoid communication (serialization/de-serialization) overhead
- Separated
- Scenario: The frequency/volume of data of interest to the Temporal stack is low
| Drawio | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|