Contributors:
Harish Kajur, Robby Maharajh, William Reehil, CT Paterson, Steven Blimkie
Overview:
- Currently, changes in schema are delivered via new builds of microservices that consume them
- Tracking and testing changes via new builds takes longer
Dublin Requirements:
- AAI schema service must support the ability to centrally persist (build-time) and serve (run-time) schema via REST
- AAI schema service must support the ability to centrally persist (build-time) and serve (run-time) custom queries via REST - removing the custom query definitions from the traversal service and making the schema service responsible for them.
- AAI schema service must support the ability to provide a complete schema as one document even if persisted via multiple files
- AAI schema service must support the ability to provide a list of documents stored
- AAI schema service must support the ability to provide an individual document
- AAI schema service must support the ability to provide associations/grouping between documents (needs more clarity)
- OXM and Edgerules paired by version [v11, v12, v13]
- Grouped by usecase w/ multiple OXM files
- AAI schema service must continue to support clients that consume the schema via XSDs and POJOs as build-time artifacts
- AAI schema service must start before the Client AAI microservices that depend on it
- Client AAI microservices that currently depend on aai-common / aai-schema artifact at build time must use the AAI schema service REST API as its source for OXM schema files and edge rules
- Client AAI microservices must support an fallback mechanism that can be optionally triggered at microservice start-time
Use cases/open questions:
- Multiple instances of AAI running with entirely separate schemas
- Scenario where an attribute is changed interactively by the user - system engineer or dev for testing/proof of concept - and then how to commit that change to the schema service to make it permanent
- Differences between build-time and run-time dependencies - current function, user updates schema file(s) and/or edge rules. This is a run-time interface to a static configuration. Even though it can be set/changed at run-time, for Dublin, the schema/edge rules will remain a build-time dependency for the schema service but is a run-time dependency for the internal AAI microservices that consume the schema service.
- AAI clients that use XSD will consume the schema service artifacts, and will not consume an XSD via REST API
- What happens when we have conflicts - what conflicts can arise and how they detected and remediated
- Auditing on multi-oxm overlap / conflicts
- Multi-oxm to split administrative types from inventory types
- Does the mutli-oxm which allows the same java-type in more than one file make sense?
- Impact on history feature - follow up with William Reehil and Robby Maharajh, invite them to next week's call to discuss
Proposed Design :
- A mS called Schema Service will hold and load all the schema (OXM and edge rules) at start up
- The Schema Service will hold and load the custom query document at start up
- The Schema Service will provide REST endpoints via GETs such as /aai/schema-service/{api-version}. Consumer mS, such as resource, traversal should use the updated ingest library to make REST calls to the Schema Service
- The REST endpoint for providing the schema will support a "format" query parameter which will describe what format it is requested in eg. GET /aai/schema-service/v1/nodes?version={version}&format=OXM
- The REST endpoints such as /aai/schema-service/v1/nodes?version={version} and /aai/schema-service/v1/edgerules?version={version} will provide a complete schema from multiple files
- The REST endpoint such as /aai/schema-service/v1/list will provide the list of documents stored
- The REST endpoint such as /aai/schema-service/v1/nodes?version={version}, /aai/schema-service/v1/edgerules?version={version} and /aai/schema-service/v1/stored-query will provide the individual document
- The REST endpoint will provide the associations between documents via query parameter "version"
- The schema jar will continue to be provided as an artifact for consumers of XSD and POJOs
Future enhancements:
- AAI should support the ability to consume new schema dynamically, without downtime (eg. when distributed by SDC)
- AAI should support the ability to notify consumers of schema when new updates are available
- AAI should support an interface to validate proposed schema changes
- AAI should support the ability to provide the schema via flexible document formats (OXM, TOSCA etc.)
#1 and #2 need more analysis of use cases and design. #3 seems to align better with the GraphGraph proposal for viewing and interfacing with the schema.