Difference between revisions of "Biodiversity Access"

From Gcube Wiki
Jump to: navigation, search
m (Philosophy)
m (Architecture)
Line 20: Line 20:
  
 
=== Architecture ===
 
=== Architecture ===
 +
Biodiversity access is provided by the following components:
 +
 +
* '''species-manager-service''': a suite of stateful Web Services that expose a tree-oriented API of read and write operations and implement it by delegation to dynamically deployable plugins for target data sources within and outside the system;
 +
 +
* '''species-manager-library''': a client library that implements a high-level facade to the remote APIs of the Tree manager services;
 +
 +
* '''obis-species-plugin''': a plugin of the Tree Manager services that defines and maintains gDM views of data sources that expose an OAI interface;
 +
 +
* '''gbif-species-plugin''': a plugin of the Tree Manager services that defines and maintains tree views of data sources that expose a SPARQL interface.
 +
 +
* '''catalogoflife-species-plugin''': a plugin of the Tree Manager services that defines and maintains gDM views of data sources that expose an OAI interface;
 +
 +
* '''flora-species-plugin''': a plugin of the Tree Manager services that defines and maintains tree views of data sources that expose a SPARQL interface;

Revision as of 17:40, 27 February 2012


A cluster of components that allows uniform access over different biodiversity repositories. 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 services have dynamically extensible architectures, 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

Handling heterogeneous biodiversity repositories with different capabilities and dissimilar results modeling is one of the main goals for biodiversity studies. This subsystem offer the possibility to retrieve, to manage and to elaborate all this data with a single entry point. The choice to not use the tree-manager subsystem was taken as the APIs are too general to use them in this specific context. In this case a domain specific APIs is needed.

Architecture

Biodiversity access is provided by the following components:

  • species-manager-service: a suite of stateful Web Services that expose a tree-oriented API of read and write operations and implement it by delegation to dynamically deployable plugins for target data sources within and outside the system;
  • species-manager-library: a client library that implements a high-level facade to the remote APIs of the Tree manager services;
  • obis-species-plugin: a plugin of the Tree Manager services that defines and maintains gDM views of data sources that expose an OAI interface;
  • gbif-species-plugin: a plugin of the Tree Manager services that defines and maintains tree views of data sources that expose a SPARQL interface.
  • catalogoflife-species-plugin: a plugin of the Tree Manager services that defines and maintains gDM views of data sources that expose an OAI interface;
  • flora-species-plugin: a plugin of the Tree Manager services that defines and maintains tree views of data sources that expose a SPARQL interface;