Module Notes

Revision as of 17:54, 23 November 2016 by Fredrik Ronquist (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

The following topics were discussed in the data model modularization discussion in Edinburgh on 2016-11-22.


The DINA-Web system can conceptually be broken down into modules representing different functionality areas, for instance taxonomy management. Each module consists of at least one web service component meeting the *API blueprint* (API contract) for the module. The module may have one or more client components giving access to the API. The clients can for instance be graphical web user interfaces, command-line interfaces or a packages for computing environments like R.


Each component (web services component or client component) should be kept in a separate git repository. This is the way the DINA-Web github project is set up currently. API blueprints should also be kept in separate git repositories to facilitate rapid prototyping and to make it easier for external developers to provide their own web service or client components.

Referential integrity

In a relational database, it is relatively straightforward to maintain referential integrity but this is not the case in a more loosely coupled modular SOA system. Our proposal is that we build modules so that they are resilient to problems with broken links and similar problems with referential integrity. Client components that deal with operations that could cause critical problems with referential integrity should have the primary responsibility for avoiding such problems, and we should not try to conserve referential integrity through implementing message queues or similar systems. The proposal will be presented to the TC for decision.

Initial modules for version 1.0

The modules that will be used in version 1.0 are:

  • Taxonomy module
  • Attachment (media) module
  • User module (keycloak)

Candidate modules for later versions are:

  • Geography names
  • Literature references

Taxonomy module

To make sure we retain flexibility, we should define a generic API for the taxonomy module web service, which allows us to use different back ends. Depending on the back end solution, a light-weight API wrapper may be needed to translate from the generic API to calls or services that are supported by the back end. It is important to collect use cases for the taxonomy module before finalizing the API, and we should assemble a list of use cases from information collected by different DINA teams. Versioning of taxonomies is going to be important to keep track of references to external taxonomies. One way of supporting versions is to store old versions as separate taxonomies.

Task groups

We need task groups to be assigned for each of the modules that should go into version 1.0, defining the API. Tasks include defining use cases, divide them into versions, defining the v1.0 API and implementing the web services and client(s).

This page was last modified on 23 November 2016, at 17:54. Content is available under Attribution-Share Alike Non-commercial 2.5 or later, Unported unless otherwise noted.