You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

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

Requirements:

  1. AAI should support the ability to centrally persist and serve schema
  2. AAI should support the ability to centrally persist and serve custom queries
  3. AAI should support the ability to provide schema documents via a loosely coupled REST contract
  4. AAI should support the ability to provide the schema via flexible document formats (OXM, TOSCA etc.)
  5. AAI should support the ability to provide a complete schema as one document even if persisted via multiple files
  6. AAI should support the ability to provide a list of documents stored
  7. AAI should support the ability to provide an individual document
  8. AAI should support the ability to provide associations between documents (eg. an OXM and Edgerules)
  9. AAI should continue to support clients that consume the schema via XSDs and POJOs
  10. AAI should support the ability to consume new schema dynamically, without downtime (eg. when distributed by SDC)
  11. AAI should support the ability to notify consumers of schema when new updates are available
  12. AAI should support an interface to validate proposed schema changes

Scope for Dublin:

#10 and #11 need more analysis of use cases. #12 seems to align better with the GraphGraph proposal for viewing and interfacing with the schema.

Delivering #1 - #9 in Dublin will enables us to move in that direction.

Proposed Design :

  1. A mS called Schema Service will hold and load all the schema (OXM and edge rules)  at start up 
  2. The Schema Service will hold and load the custom query document at start up
  3. 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
  4. 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
  5. 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
  6. The REST endpoint such as /aai/schema-service/v1/list will provide the list of documents stored 
  7. 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
  8. The REST endpoint will provide the associations between documents via query parameter "version"
  9. The schema jar will continue to be provided as an artifact for consumers of XSD and POJOs 


  • No labels