Difference between revisions of "Environmental Service"
(→Architecture) |
|||
| Line 3: | Line 3: | ||
|} | |} | ||
| − | A broker for searching among geo-referenced data sources, aiming to provide users and services with tools for retrieving information about environmental characteristics. | + | A broker for searching among geo-referenced data sources, aiming to provide users and services with tools for retrieving information about environmental characteristics in a standard [http://www.opengeospatial.org/ OGC] format. |
This document outlines the design rationale, key features, and high-level architecture, as well as the options deployment. | This document outlines the design rationale, key features, and high-level architecture, as well as the options deployment. | ||
== Overview == | == Overview == | ||
| − | The goal of this service is to offer a unique access for retrieving geo-spatial data which could | + | The goal of this service is to offer a unique access for retrieving geo-spatial data which could contain environmental data, chemical or physical information about terrestrial or oceanic areas. Data can be yet present in the d4Science Infrastructure or they could be obtained by processing resident information. In some cases data have to be downloaded from external sources. |
| − | The Service is able to take requests coming from clients or services under many formats and answers by producing OGC | + | The Service is able to take requests coming from clients or services under many formats and answers by producing OGC compliant documents. These include WPS, WCS, WMS and WFS formats. |
Connectors towards data providers are implemented as plug-ins which makes the injection mechanism of new functionalities easy to deploy. | Connectors towards data providers are implemented as plug-ins which makes the injection mechanism of new functionalities easy to deploy. | ||
| Line 18: | Line 18: | ||
=== Philosophy === | === Philosophy === | ||
| − | This represents a unique endpoint for those clients or services which want to perform | + | This represents a unique endpoint for those clients or services which want to perform geo-spatial analysis on some data or want to retrieve environmental characteristics about earth areas. |
Further details are available at the [https://gcube.wiki.gcube-system.org/gcube/index.php/GCube_Features Geo Spatial Facilities Section] on the gCube wiki. | Further details are available at the [https://gcube.wiki.gcube-system.org/gcube/index.php/GCube_Features Geo Spatial Facilities Section] on the gCube wiki. | ||
| Line 25: | Line 25: | ||
The subsystem comprises the following components: | The subsystem comprises the following components: | ||
| − | * '''MyOcean Connector''': a connector to the MyOcean | + | * '''MyOcean Connector''': a connector to the [http://www.myocean.eu.org/ MyOcean] data source for retrieving physical and chemical earth features; |
| − | * '''Thredds Connector''': a connector to | + | * '''Thredds Connector''': a connector to a [http://www.unidata.ucar.edu/projects/THREDDS/ THREDDS] server which retrieves stored geo-spatial information in OGC standard format; |
| − | * '''WPS Connector''': a connector to a WPS Service ([http://52north.org/communities/geoprocessing/wps/index.html | + | * '''WPS Connector''': a connector to a WPS Service (a [http://52north.org/communities/geoprocessing/wps/index.html 52 North] implementation) which provides extraction functionalities from net-CDF files or environmental layers; |
* '''Environmental Service''': the Service Core which implements the orchestration logic. | * '''Environmental Service''': the Service Core which implements the orchestration logic. | ||
| Line 39: | Line 39: | ||
== Deployment == | == Deployment == | ||
| − | All the components of the service must be deployed together in a single node. This subsystem can be replicated | + | All the components of the service must be deployed together in a single node. This subsystem can be replicated on multiple hosts and scopes, this does not guarantee a performance improvement because this is associated to the requests which are made towards external sources. |
| − | There are no temporal constraints on the co-deployment of services and | + | There are no temporal constraints on the co-deployment of services and plug-ins. Every plug-in must be deployed on every instance of the service. |
The Service will automatically take the available sources by asking to the d4Science Information System for the scope it is running into. | The Service will automatically take the available sources by asking to the d4Science Information System for the scope it is running into. | ||
| Line 52: | Line 52: | ||
=== Well suited Use Cases === | === Well suited Use Cases === | ||
| − | The subsystem is particularly suited to support abstraction over geo-spatial information retrieval both in cases of environmental data or time series or other formatted data which | + | The subsystem is particularly suited to support abstraction over geo-spatial information retrieval both in cases of environmental data or time series or other formatted data which have geo-spatial information associated. It is suitable when the production of standard OGC format documents is needed. |
| − | The development of any | + | The development of any plug-in for the Environmental Service immediately extends the ability of the systems to interact with other kinds of geo-spatial data sources. |
Revision as of 14:12, 11 May 2012
A broker for searching among geo-referenced data sources, aiming to provide users and services with tools for retrieving information about environmental characteristics in a standard OGC format. This document outlines the design rationale, key features, and high-level architecture, as well as the options deployment.
Overview
The goal of this service is to offer a unique access for retrieving geo-spatial data which could contain environmental data, chemical or physical information about terrestrial or oceanic areas. Data can be yet present in the d4Science Infrastructure or they could be obtained by processing resident information. In some cases data have to be downloaded from external sources.
The Service is able to take requests coming from clients or services under many formats and answers by producing OGC compliant documents. These include WPS, WCS, WMS and WFS formats.
Connectors towards data providers are implemented as plug-ins which makes the injection mechanism of new functionalities easy to deploy.
Design
Philosophy
This represents a unique endpoint for those clients or services which want to perform geo-spatial analysis on some data or want to retrieve environmental characteristics about earth areas.
Further details are available at the Geo Spatial Facilities Section on the gCube wiki.
Architecture
The subsystem comprises the following components:
- MyOcean Connector: a connector to the MyOcean data source for retrieving physical and chemical earth features;
- Thredds Connector: a connector to a THREDDS server which retrieves stored geo-spatial information in OGC standard format;
- WPS Connector: a connector to a WPS Service (a 52 North implementation) which provides extraction functionalities from net-CDF files or environmental layers;
- Environmental Service: the Service Core which implements the orchestration logic.
A diagram of the relationships between these components is reported in the following figure:
Deployment
All the components of the service must be deployed together in a single node. This subsystem can be replicated on multiple hosts and scopes, this does not guarantee a performance improvement because this is associated to the requests which are made towards external sources. There are no temporal constraints on the co-deployment of services and plug-ins. Every plug-in must be deployed on every instance of the service.
The Service will automatically take the available sources by asking to the d4Science Information System for the scope it is running into.
Small deployment
The deployment follows the schema of the Architecture, as it implies the THREDDS, WPS and MyOcean Services are running in the same scope.
Use Cases
Well suited Use Cases
The subsystem is particularly suited to support abstraction over geo-spatial information retrieval both in cases of environmental data or time series or other formatted data which have geo-spatial information associated. It is suitable when the production of standard OGC format documents is needed. The development of any plug-in for the Environmental Service immediately extends the ability of the systems to interact with other kinds of geo-spatial data sources.
