Difference between revisions of "Facilities Specification Template"

Revision as of 16:13, 3 February 2012

This is a tentative proposal for Facilities Specifications. According to the iMarine DoW, the following Facilities should be documented by using this template:

• WP8 - iMarine Data e-Infrastructure Enabling-technology Development
  • Data e-Infrastructure Management Facilities
  • Data e-Infrastructure Policy-oriented Security Facilities
  • Workflow Management Facilities
• WP9 - Data Management Facilities Development
  • Data Access and Storage Facilities
  • Data Transfer Facilities
  • Data Assessment, Harmonisation, and Certification Facilities
• WP10 - Data Consumption Facilities Development
  • Data Retrieval Facilities
  • Data Manipulation Facilities
  • Data Mining Facilities
  • Data Visualisation Facilities
• WP11 - Data e-Infrastructure Integration and Interoperability Facilities Development
  • Data Management APIs
  • Data Consumption APIs

In addition to that, a number of applications will be developed, namely by combining these facilities in predefined workflows. These might stem from WP6 activities. These applications will be described through the same template.

Overall we should refrain from using terminology that is inherited by the project organisation, namely WPs and Tasks.

For each of the above described facilities, the following sections should be created: Overview, Key Features and Subsystems.

Overview

Few lines with a promotional 'flavour', e.g. "gCube xxx facilities offer scalable, high-performance, reliable, open source instruments for ..."

Key Features

A bullet list highlighting the main features offered by the facilities. The 'flavour' should be catchy and user-friendly. Some examples are (from MongoDB):

Document-oriented storage

JSON-style documents with dynamic schemas offer simplicity and power.

Full Index Support

Index on any attribute, just like you're used to.

Replication & High Availability

Mirror across LANs and WANs for scale and peace of mind.

Auto-Sharding

Scale horizontally without compromising functionality.

Subsystems

Because

1. the identified facilities might be quite extent / "fat" from the functional point of view and
2. the information introduced so far is very generic from a technical point of view

one or more 'subsystem' pages might be created. Each subsystem page is expected to provide the reader with a description capturing design and deployment aspects as well as supported 'use cases'. The following template is proposed:

Subsystem Specification Template

It will be great if we manage to identify the subsystems.