1 / 17

v-GISC Presentation – ET_WISC – Geneva - February 3 2010

v-GISC Presentation – ET_WISC – Geneva - February 3 2010. v-GISC key functionalities ET_WISC meeting 2-5 February 2010. Jean-Pierre Aubagnac, Jacques Roumilhac Météo-France. General Requirements.

nike
Télécharger la présentation

v-GISC Presentation – ET_WISC – Geneva - February 3 2010

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. 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

  3. 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)

  4. Functional Components and Interfaces Global data and products are collected from the Partners acquisition systems and stored for 24 hours in a GISC Cache.

  5. 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.

  6. Functional Components and Interfaces Synchronization processes among GISCs guarantee a global and current content of the Cache and Catalogue.

  7. Functional Components and Interfaces Authenticated and authorized users can compose requests on data and products discovered in the Catalogue.

  8. 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.

  9. Functional Components and Interfaces Requested data are delivered via the software interface to the local dissemination system.

  10. 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.

  11. 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

  12. 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

  13. 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

  14. 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

  15. 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

  16. 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

  17. 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

More Related