Home
Forgot your password?
New user?
Oceans IE Phase II kickoff meeting
OOSTethys Architecture
Definition and interfaces of the different components of an ocean observing system, within OOSTethys.
Table of Contents
- Introduction
- Use cases
- Architecture among distributed ocean observing systems
- Ocean observing system (OOS) architecture
- Definition of components
Introduction
This section details use cases and a Service Oriented Architecture (SOA) for ocean observing systems. Our best practices of how to implement those components are detailed here.
top of pageUse cases
Components of the system should be able to perform requests based on a basic query dimension, which is defined as follows:
- bounding box (lat, lon, depth)
- time limits
- parameter type
- source type
The latest UML sequence diagrams defining the interfaces are here:
top of page
Architecture among distributed ocean observing systems
OOS will interact each other via registries, to extract metadata about the services available in an OOS.
top of page
Ocean observing system (OOS) architecture
OOSTethys service architecture is composed of the following components: Data Provider , Service Registry, Semantic Mediator, Data Aggregator , Visualizer and Archiver. The rationale and interfaces for these components are explained bellow.
top of page
Data Provider
The Data Provider is responsible for serving data from instruments (in situ sensors or samplers), creating post products (e.g., time series averaging, quality control processing), or serving numerical model runs. The Data Provider is also responsible for storing his own data and registering the details of the services that it has made available. Services are defined in a service-contract, negotiated between cooperative entities with similar data and data sharing requirements. These could entail SOAP services, OGC services such as WMS WFS or WCS. In the case of OOSTethys we currently concentrate on OGC Sensor Observations Services (SOS).
| Interface | Description | Format | Link Specification |
|---|---|---|---|
| getCapabilities | Returns information of how to call the service, what sources (Platforms, sensors, detectors) it contains, and the observation offering details ( bounding box, parameters, time interval) | Rest XML | OGC SOS |
| describeSensor | Returns metadata about the systems or processes that produces an observation (e.g. observing systems, platforms, sensors). Metadata includes contact information, inputs and outputs, and identification and classification metadata. | Rest XML | OGC SOS |
| getObservation | Returns the data or link to it, and the necessary information to be able to understand and processes it ( e.g. units, semantics ). | Rest XML | OGC SOS |
Semantic Mediator
A semantic mediator allows to register a vocabulary, register mappings of vocabularies and perform update and queries of existing register vocabularies. For example the relation "upward_sea_water_velocity" in the CF vocabulary could be found to be narrower than "Ocean Currents" from the GCMD vocabulary. If CF, GCMD and mappings are all stored in the semantic mediator, a portal could query all the narrower terms for Oceans Currents, and get, for example "upward_sea_water_velocity". If services responses (SOS, WFS, WMS, etc..) are tagged with known, register vocabularies, the semantic mediator could hep find the commonalties of those services. The MMI Registry is available at: http://mmisw.org/or.
| Interface Description | Link Specification |
|---|---|
|
The interface supported is HTTP GET/POST, using SPARQL. End point is http://mmisw.org/ont/ Only one parameter is needed: sparql The value is a SPARQL string. | Examples and more information about SPARQL |
Service Registry
A registry is a system build on top of a register. A Service Registry allows to services providers to register their services and allows service consumers to discover services. Services could be data services, translations services or others. OOSTethys currently supports a simple services for SOS services.
|
Interface
|
Description
|
Format
|
Link Specification
|
|---|---|---|---|
|
Register Provider
|
Registers the provider by calling the SetCapabilities service, which calls the provider’s GetCapabilities service related services ( e.g. Describe Sensor in SOS) | REST XML | http://score.itsc.uah.edu/MMI/ |
|
Get Valids
|
Returns all valid values from all searchable fields in registry
|
REST XML | Documentation |
|
Get URLs
|
Returns observation offerings and/or sensors from registry
|
REST XML
|
Documentation |
Detailed description and usage of these services are described
in this PDF document.
Data Aggregator
The Data Aggregator will temporary store data from Data Provider, and could create a post product, facilitating clients ( e.g. visualization portals) to get the data client’s need. Therefore, a Data Aggregator is also a data provider. A Data Aggregator could be embedded in a visualization portal on in the archiver. Currently at OOSTethys this function is performed by the visualization portal, OpenIOOS.
top of pageData Archiver
The Archiver is a data storage site that acquires data from Data Providers and Data Aggregators. An Archiver may not hold all records from all Data Providers, if data are maintained in a distributed archival method. Data Providers may serve as Archivers. Archivers will establish a policy for data retention, and a manner to ensure data provanence. The Archiver will receive information on services from one or more Registries.
top of page
Visualization Portal
A visualization portal is the tool the end user (modeling scientist) will interact with. For example, is a decision support or discovery tool. At OOSTethys OpenIOOS provides a GoogleMap where users could scroll, zoom and filter by organization or parameter to discover the data of interest.
