WP11: API Cases Identification Report Template

Label

A distinctive label in the form of a single line title is assigned to each case for an API of the functional area. Wiki URL and track tickets have to be bound with this title. The case can obtain also an ID and then can be bound to the Track Ticket when the case comes into implementation.

Objective

A short description of the objective of the API case.

Area Working Group

The working group that deals with the case.

Detailed Description

This section contains the detailed verbal description of the API case of the functional area and is expected to be quite extended when complete.

The following topics should be covered by the description of a case:

• Verbal description that refers to details of resources interactions. This should contain:
  • Resources Analysis
    • Definition of the flows of resources (data, facilities, etc.) that fall under the corresponding infrastructure layer
    • Examination of the significance of the resources involved and the multiplicity of facets they expose
  • Options and Needs Analysis
    • Examination of the overall infrastructure's capabilities and the requirements for their exploitation by other resources
    • Designation of perceptions of flows' needs and opportunities
    • Definition of the given options
  • API Integration
    • Analysis of operations that will promote integration and interoperability based on previous designation of needs and opportunities
• Specifications' descriptions
  • • Description of specifications with a justification for their placement in the case
  • Optional abstract diagrams of interactions (flow/control)

Indicatively diagrams should fall under the Behavior or Interaction classification of UML diagrams.

Case evaluation

A divided section of costs and benefits of the designed case, for assisting the evaluation of the case. The following sections should be identified.

Case benefits

All the benefits brought to the ecosystem by the case have to be enumerated and if possible quantified:

• Security of the case: i.e. how safe the realization of a case is. (If a case is risky, then this attribute goes into the cons)
• gCube issues addressed
• iMarine project opportunities opened
• New resources brought in either direction
• Case reuse (beyond even interoperability)
• Case alignment with the objective of the project, the nature of the systems, and other cases

Case implications and risks

There are several reasons for classifying a case as risky:

• standards are missing
• the effort is not clear
• too many dependencies identified
• the expected expoitation of the case is not secure

etc.

All these have to be identified as part of the case evaluation.

Implementation cost and time line

The estimation of the overall case implementation cost and timeline is quite valuable for the evaluation of a case and its promotion to follow an implementation path and as such it has to be provided.

Targeted Resources Sum-up

The section includes a sum-up of the identified resources involved into the API case. For each resource the consumption direction and the objectives of the interaction should be identified. Additionally references to protocols/specifications should be assigned to each case. It is expected that all resources enumerated here, are referenced in the case description too.

Each involved iMarine resource that participates an API case as part of the D4ScienceAn e-Infrastructure operated by the D4Science.org initiative. infrastructure has to be described in terms of:

• Role of the resource
• Protocols
• Participation need (mandatory/desired/optional)

Protocols/Specifications Sum-up

The reference of the protocols / specifications involved in the case can be enriched with flags labeling them as:

• required/desired/optional/speculated
• existing/extension/new