Biodiversity Access
Part of the Data Access and Storage Facilities, a cluster of components within the system focus on uniform access to sources of biodiversity data of arbitrary location and size.
This document outlines their design rationale, key features, and high-level architecture, as well as the options for their deployment.
Overview
The goal of this subsystem is to offer an uniform access over different biodiversity repositories through a simple API.
The service has dynamically extensible architecture, i.e. rely on independently developed plugins to adapt their APIs to a variety of back-ends within or outside the system.
When connected to remote data sources, the services may be widely replicated and their replicas know how to leverage the Enabling Services to scale horizontally to the capacity of the remote back-ends.
Design
Philosophy
Uniform access to sources of biodiversity data that expose different capabilities and different data models is a key requirement to support biodiversity studies.
This subsystem offer the possibility to retrieve, manage and elaborate biodiversity data under a single model, with a domain-specific API, and regardless of its source of origin.
Architecture
The subsystem comprises the following components:
- species-manager-service: a stateless Web Service that exposes read operations and implements it by delegation to dynamically deployable plugins for target repository sources within and outside the system;
- species-manager-library: a client library that implements a high-level facade to the remote APIs of the Species manager service;
- obis-sm-plugin: a plugin of the Species Manager service that interacts with [http:// OBIS] data source;
- gbif-sm-plugin: a plugin of the Species Manager service that interacts with [http:// GBIF] data source;
- col-sm-plugin: a plugin of the Species Manager service that interacts with [http:// Catalogue of Life] data source;
- flora-sm-plugin: a plugin of the Species Manager service that interacts with [http:// Brazilian Flora] data source.
A diagram of the relationships between these components is reported in the following figure:
Deployment
All the components of the subsystem must be deployed together in a single node. This subsystem can be replicated in multiple hosts; this does not guarantee a performance improvement because the scalability of this system depends on the capacity of external repositories contacted by the plugins.
Large deployment
A deployment diagram suggesting the deployment schema that maximizes scalability should be described here.
Small deployment
Use Cases
The subsystem has been conceived to support a number of use cases moreover it will be used to serve a number of scenarios. This area will collect these "success stories".
Well suited Use Cases
Describe here scenarios where the subsystem proves to outperform other approaches.
Less well suited Use Cases
Describe here scenarios where the subsystem partially satisfied the expectations.