Contributors

Glossary

Term	Definition
AAI-internal-clients	Sub-projects of AAI that are direct clients of schema services (currently have dependency on aai-schema-ingest library) including: data-router, gizmo, resources, router-core, sparky-be, spike, traversal, validation Sub-projects of AAI that are indirect clients of schema services (via aai-common library) or are schema-agnostic including: babel, cacher, chameleon, champ, eis, enricher, esr, gallifrey, graphadmin, graphgraph, logging-service, model-loader, rest-client, search-data-service, sparky-fe, tabular-data-service
ONAP-project-clients	Projects of ONAP that are definitely clients of AAI including: DCAE (evidenced by https://gerrit.onap.org/r/#/c/73148/ change for rest-services/aai-client component) APPC and CCSK (evidenced by CCSDK-740 - Getting issue details... STATUS / CCSDK-741 - Getting issue details... STATUS bug for named-query and XSD schema of response data) Projects of ONAP that are likely clients of AAI including: CLAMP, DMaaP, ExtAPI, Holmes, MSB, MultiVIM, OOM, Policy, Portal, SDC, SO, SDNC, VFC, VNFSDK, VID, UUI
producer-consumer pairings	Apart from "internal" AAI data, the data in AAI is produced by some other component and then consumed by another component. Therefore the schema definitions and intended meanings of each schema element is not controlled by AAI itself. For example in VFC-1193 - Getting issue details... STATUS , OOF-to-VFC pairing for this scenario: VFC component sources the "flavor name" from OOF component Then VFC searches AAI using "flavor name" to find the corresponding "flavor id" Finally "flavor id" is used to create a VM
deployment tools	Tools (e.g. Helm, ansible, Docker Compose, etc) used to: place the microservices into their run-time environment distribute data files for initial configuration perform the initial configuration of microservices get the ONAP system running as intended
IDL Files	Some form of "Interface Definition Language" which unifies and replaces the OXM files and EdgeRule files as definition of AAI schema
Purple highlights	Highlight change from predecessor ONAP Release

References

Use Case Outlines

ONAP Release Target	Use Case Summary	Deprecated Functions
Amsterdam, Beijing	AAI Schema is: single-data-file configuration per version, i.e. one OXM file and one EdgeRule file distributed via source-code repository to AAI-internal-clients and ONAP-project-clients built into and deployed as microservice JAR file effective only upon microservice startup
Casablanca	AAI Schema is: multiple-data-file configuration, i.e. multiple OXM files and multiple EdgeRule files distributed via source-code repository to AAI-internal-clients and ONAP-project-clients built into and deployed as microservice JAR file effective only upon microservice startup	single-data-file configuration per version
Dublin	AAI Schema is: multiple-data-file configuration distributed as data files via deployment tools to AAI-internal-clients, i.e. multiple OXM files and multiple EdgeRule files, without change to JAR files effective only upon AAI-internal-clients startup distributed as data files via deployment tools to AAI Schema Service, i.e. multiple OXM files and multiple EdgeRule files effective only upon AAI Schema Service startup distributed via run-time API to AAI-internal-clients effective only upon AAI-internal-clients startup distributed via source-code repository to ONAP-project-clients, i.e. XSD files and generated POJOs built into and deployed as ONAP-project-clients JAR file effective only upon ONAP-project-clients startup	single-data-file configuration per version distributed via source-code repository to AAI-internal-clients built into and deployed as microservice JAR file
Dublin and beyond	Each of the AAI-internal-clients and ONAP-project-clients will need to identify the relevant pieces of AAI schema that relates uniquely to their operations. The multiple-data-file configuration to be grouped by producer-consumer pairings.
Dublin and beyond	Each of the AAI-internal-clients will need to decide when/how to proceed with changing over to the updated methods of distributing the AAI schema.
El Alto	AAI Schema is: multiple-data-file configuration distributed as data files via deployment tools to AAI-internal-clients, i.e. multiple OXM files and multiple EdgeRule files, without change to JAR files effective upon AAI-internal-clients run-time refresh distributed as data files via deployment tools to AAI Schema Service, i.e. multiple OXM files and multiple EdgeRule files effective upon AAI Schema Service run-time refresh distributed via run-time API to AAI-internal-clients effective upon AAI-internal-clients run-time refresh distributed as data files via deployment tools to ONAP-project-clients without change to JAR files effective only upon ONAP-project-clients startup	single-data-file configuration per version distributed via source-code repository to AAI-internal-clients built into and deployed as microservice JAR file effective only upon AAI Schema Service startup effective only upon AAI-internal-clients startup distributed via source-code repository to ONAP-project-clients XSD files and generated POJOs
El Alto and beyond	Each of the ONAP-project-clients will need to decide when/how to proceed with changing over to the updated methods of distributing the AAI schema.
Frankfurt	AAI Schema is: multiple-data-file configuration distributed as data files via deployment tools to AAI-internal-clients, i.e. multiple IDL files, without change to JAR files effective upon AAI-internal-clients run-time refresh distributed as data files via deployment tools to AAI Schema Service, i.e. multiple IDL files effective upon AAI Schema Service run-time refresh distributed via run-time SDC API to AAI Schema Service, i.e. multiple TOSCA files and CSAR files effective upon AAI Schema Service run-time refresh distributed via run-time API to AAI-internal-clients effective upon AAI-internal-clients run-time refresh distributed as data files via deployment tools to ONAP-project-clients without change to JAR files effective only upon ONAP-project-clients startup	single-data-file configuration per version distributed via source-code repository to AAI-internal-clients built into and deployed as microservice JAR file effective only upon AAI Schema Service startup effective only upon AAI-internal-clients startup distributed via source-code repository to ONAP-project-clients XSD files and generated POJOs multiple OXM files and multiple EdgeRule files
G release	AAI Schema is: multiple-data-file configuration distributed as data files via deployment tools to AAI-internal-clients, i.e. multiple IDL files or multiple TOSCA files and CSAR files, without change to JAR files effective upon AAI-internal-clients run-time refresh distributed as data files via deployment tools to AAI Schema Service, i.e. multiple IDL files or multiple TOSCA files and CSAR files effective upon AAI Schema Service run-time refresh distributed via run-time SDC API to AAI Schema Service, i.e. multiple TOSCA files and CSAR files effective upon AAI Schema Service run-time refresh distributed via run-time API to AAI-internal-clients effective upon AAI-internal-clients run-time refresh distributed as data files via deployment tools to ONAP-project-clients without change to JAR files effective only upon ONAP-project-clients startup distributed via run-time API to ONAP-project-clients effective only upon ONAP-project-clients startup	single-data-file configuration per version distributed via source-code repository to AAI-internal-clients built into and deployed as microservice JAR file effective only upon AAI Schema Service startup effective only upon AAI-internal-clients startup distributed via source-code repository to ONAP-project-clients XSD files and generated POJOs multiple OXM files and multiple EdgeRule files
G release and beyond	Each of the ONAP-project-clients will need to decide when/how to proceed with changing over to the updated methods of distributing the AAI schema.
H release and beyond	AAI Schema is: multiple-data-file configuration distributed as data files via deployment tools to AAI-internal-clients, i.e. multiple IDL files or multiple TOSCA files and CSAR files, without change to JAR files effective upon AAI-internal-clients run-time refresh distributed as data files via deployment tools to AAI Schema Service, i.e. multiple IDL files or multiple TOSCA files and CSAR files effective upon AAI Schema Service run-time refresh distributed via run-time SDC API to AAI Schema Service, i.e. multiple TOSCA files and CSAR files effective upon AAI Schema Service run-time refresh distributed via run-time API to AAI-internal-clients effective upon AAI-internal-clients run-time refresh distributed as data files via deployment tools to ONAP-project-clients without change to JAR files effective upon ONAP-project-clients run-time refresh distributed via run-time API to ONAP-project-clients effective upon ONAP-project-clients run-time refresh	single-data-file configuration per version distributed via source-code repository to AAI-internal-clients built into and deployed as microservice JAR file effective only upon AAI Schema Service startup effective only upon AAI-internal-clients startup distributed via source-code repository to ONAP-project-clients XSD files and generated POJOs multiple OXM files and multiple EdgeRule files effective only upon ONAP-project-clients startup
I release and beyond	AAI Schema is: federation of AAI instances with disjoint schemas and databases facade to stitch disjoint schema and data back into a unified representation schema change and version upgrade by deploying new AAI instance to join federation rolling upgrade and data migration between AAI instances within federation multiple-data-file configuration distributed as data files via deployment tools to AAI-internal-clients, i.e. multiple IDL files or multiple TOSCA files and CSAR files, without change to JAR files effective upon AAI-internal-clients run-time refresh distributed as data files via deployment tools to AAI Schema Service, i.e. multiple IDL files or multiple TOSCA files and CSAR files effective upon AAI Schema Service run-time refresh distributed via run-time SDC API to AAI Schema Service, i.e. multiple TOSCA files and CSAR files effective upon AAI Schema Service run-time refresh distributed via run-time API to AAI-internal-clients effective upon AAI-internal-clients run-time refresh distributed as data files via deployment tools to ONAP-project-clients without change to JAR files effective upon ONAP-project-clients run-time refresh distributed via run-time API to ONAP-project-clients effective upon ONAP-project-clients run-time refresh	single-data-file configuration per version distributed via source-code repository to AAI-internal-clients built into and deployed as microservice JAR file effective only upon AAI Schema Service startup effective only upon AAI-internal-clients startup distributed via source-code repository to ONAP-project-clients XSD files and generated POJOs multiple OXM files and multiple EdgeRule files effective only upon ONAP-project-clients startup single unified AAI schema and database
J release and beyond	???

AAI Schema Service Use Case Proposals

Contributors

Glossary

References

Use Case Outlines