ET_WISC Geneva 2-5 February 2010 v-GISC key functionalities Jean-Pierre Aubagnac, Jacques Roumilhac Météo-France.

Download Report

Transcript ET_WISC Geneva 2-5 February 2010 v-GISC key functionalities Jean-Pierre Aubagnac, Jacques Roumilhac Météo-France.

ET_WISC Geneva 2-5 February 2010
v-GISC key functionalities
Jean-Pierre Aubagnac, Jacques Roumilhac
Météo-France
General Requirements
 A versatile software allowing operation of all 3 GISC, DCPC and NC functions, either
individually or combined.
 A configurable software (Portal look & feel, flow accross interfaces, request processing and
storage, etc)
 A flexible design, allowing easy substitution of one functional component, or addition of a
new functionality
 A scalable software in terms of volume of data handled (collection, storage, processing,
exchanges accross Sites)
 Fit for now, scalable for the future
 A reliable software, aiming at continuous 24x7 operations
 Supporting in priority the circulation of High Priority Safety Critical Data
 Data and Metadata integrity must be maintained
 A secure software keeping private or critical information confidential
Functional Components and Interfaces
 External Interfaces needed to:
• other WIS Centres deploying the same software or perhaps other implementations.
• the local systems (Harness to adapt generic interfaces):
• Acquisition systems (e.g. MSS and FSS),
• Dissemination systems,
• Local data sources (Archives, Product Creation systems)
Functional Components and Interfaces
Global data and products are collected from the Partners acquisition systems and stored for
24 hours in a GISC Cache.
Functional Components and Interfaces
The software holds a Catalogue of all meteorological data and products, in the form of a
Catalogue of Discovery Access and Retrieve Metadata (DAR).
The Portal offers browse and search facilities. Metadata records can be created via an
editor, imported or harvested from NCs or DCPCs.
Functional Components and Interfaces
Synchronization processes among GISCs guarantee a global and current content of the
Cache and Catalogue.
Functional Components and Interfaces
Authenticated and authorized users can compose requests on data and products discovered
in the Catalogue.
Functional Components and Interfaces
Local requests are for locally Cached or locally produced data, on an ad-hoc basis or as a
recurrent subscription. Local products can be retrieved via the interfaces to local data
sources: archive or product creation system.
Functional Components and Interfaces
Requested data are delivered via the software interface to the local dissemination system.
Functional Components and Interfaces
All software functionalities are administered, monitored and controlled. The Portal offers a
set of user interfaces for authorized local administrators and operators.
Data Service
 Generic interface to the Partners’ acquisition systems to collect Global operational data and other data
(collection and supply of products, some administration of product routeing, some monitoring)
 An entry in the DAR Metadata Catalogue must (already) exist for every collected data
 Collected product feed a Cache. Cached Products expire after a configurable duration.
 A configurable part of the Cache content is « replicated »: shared with other WIS Centres. Replication
avoids infinite loops and supports High Priority Data in priority
 Authenticated and authorized users can submit requests for locally Cached or locally produced data, on
an ad-hoc basis or as a recurrent subscription
 While processing requests, products can be retrieved from local data sources via a generic interface
 Generic configurable interface to a dissemination tool (supply of product & instructions, some
monitoring). The transport method must be adapted to the data prority and size
Metadata Service
 The software must hold a Metadata Catalogue for the Discovery, Access and Retrieval (DAR) of
meteorological data
 The Catalogue must support metadata for datasets (WMO Profile of ISO 19115) of any granularity, as
well as services operating on meteorological datasets (e.g. ISO 19119)
 Some flexibility is required to accept and understand Metadata from other WMO Programmes
 In/Out
• Flexible and configurable Import and Export facility
• Flexible and configurable Harvesting from remote Metadata Source (e.g. OAI-PMH or CSW v2.0.2)
• Metadata Editor
 A configurable part of the Catalogue must be synchronized with other WIS Centres
 Catalogue must be Queriable / Searchable (e.g. via ISO 23950)
 Basic search on keywords (full text), subject terms, spatial bounding boxes, date / time ranges
 Via configuration: Search possible on any combination of ISO19115 elements
Security Service
• Needed Data Policies range from global, regional, project orientated, to
centre specific or even user specific
• Data Policy defined as a list of privileges allotted to a group of users for
a given class of products
• Access control needed to the software «private» functions such as
administration & monitoring
 The software must provide User Authentication (who the User is)
The software must accept simultaneously anonymous users and authenticated users
 Both human interface and machine service interface for Authentication
 Different Authentication schemes supported, default login / password, presentation of certificates, etc.
 The software must provide Authorization (what the user is allowed to do)
 Users may access particular metadata, data or software functionality only if they have the appropriate
authorization
Monitoring & Control Service
 Monitoring is needed for all software functionalities
 Different levels of event severity must be recognized (Information,
Warning, Critical)
 Issueing Warning messages must be possible
 All details must be possibly logged for all data transactions, metadata
modifications, operators actions, user interactions with the software, etc.
 Reporting must be possible upon administrator request, based on the
content of logs
 A set of user interfaces is needed to allow local administrators and
operators to control the flow of data and metadata between Centres, and
between the software and users
 Advanced monitoring and reporting optionally procured as a Conditional
Tranche
Portal & User Interfaces
 A Set of Web Interfaces is required for the Discovery, Access and Retrieval of meteorological data, and
for the authorized administration and monitoring of the software.
 User Interfaces must be configurable (look and feel, multi-language support), flexible, scalable, modular
 The Portal must accepts both anonymous (guest) users and authenticated users
 The Portal must meet security requirements
 End User functions:
• User registration, User Authentication, Monitoring of a User’s own details
• Discovery (public function): search and browse of the DAR Catalogue,
• Composition of subscriptions and ad-hoc requests for products,
• User Management of their subscriptions and ad hoc requests,
• User Monitoring of their subscriptions and ad hoc requests,
• Etc
 Administrative functions:
• To administer, monitor and control software functions, software security, users, data, metadata,
exchanges via exposed interfaces
• Both web-based and command line interfaces would be a plus
External Interfaces
 A Service Oriented Layer destined to adapt / group interfaces exposed by other software services
 Configurable GISC-to-GISC interface including Cache Replication, DAR Synchronization, Authentication
and Authorization
•Security interface with other deployments of the
software
•Interface to the Partners’ acquisition systems for
the collection of data
•Interface to the Partners’ dissemination tools
•Interface to the Partners’ data sources
Candidate Implementation
 Open-source bricks proposed as candidates for major software functions: SIMDAT, GeoNetwork,
OpenSSO, etc
 Candidate Implementation documented with:
•Content Analysis or possible functional contributions of the Candidates
•Possible Architecture including information flows and information model
•Description of external interfaces, several associated use cases