Internal Service APIs

Owned by bcarlsen (Unlicensed)
Jun 01, 2015
2 min read

Overview

Documents the internal service APIs.

This is a placeholder page with basic information and will be developed to fully document this aspect of the system.

Details

There is a collection of internal APIs that provide the core functionality. Applications could be developed to use a “within JVM” connection to these services and through JPA lazy initialization entire graphs of objects can be read from the database (in either their current state or any desired past state).  

Data model access methods generally take either internal ids or terminology-specific assigned identifiers a nd return individual objects without any eagerly initialized connected data. For example, a concept obtained from the content service will simply be a concept entry without atoms or relationships. Asking a concept for its atoms will load them automatically from the database. A custom “graph resolver” is used to customize (and normalize) the amount of default information made available at the REST layer.

Methods that create objects make use of a configurable identifier assignment algorithm that can support a variety of modes, including application-managed assignment, assignment of UUIDs based on hashes of “identity” content, or delayed ID assignment until release time. The recommended assignment of concept identifiers is based on the presence of some connected data (parent concepts and prefered name) and the preferred option is to dynamically compute these identifiers as the content changes. This mechanism allows for dual independent review, where multiple authors can create and model the same concept independent of each other followed by a later conflict identification and resolution step. Though this is not required.

In general, methods that find data return search result objects with identifiers (with display labels) that can be used to perform subsequent lookups to retrieve the underlying model objects. These methods typically also take a paging/sorting/filtering parameter to allow for controlled access to the desired amount of data.

General Design

  • getXXX methods return objects (and don't take PFS)
  • findXXX methods return Lists (and take PFS - and  need to fully support it - or throw exceptions).
    • SearchResultList vs. object list

 

Security Service

TODO: more details, including use cases

Metadata Service

TODO: more details, including use cases

Content Service

TODO: more details, including use cases

History Service

TODO: more details, including use cases

Future Services

  • ValidationService
  • Editing services
  • Action service (likely migrate all admin calls here and fully implement progress monitoring).
  • n/a