Integration and Interoperability Functional Area Analysis Template

Label

A distinctive label in the form of a single line title is assigned to each functional area.

Objective

A short description of the objective of the functional area.

Working Group

The working group in charge of the functional area.

Facilities offered

An enumeration of the facilities that fall in the infrastructure layer corresponding to the functional area

Detailed Description

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

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

• Verbal description that refers to details of resources interactions. This should contain:
  • 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 area
• Optional abstract diagrams of interactions (flow/control). Indicatively diagrams should fall under the Behavior or Interaction classification of UML diagrams

Specific API Cases

Identification of the specific API cases (per protocol/technology or per specification) that fall under the category, based on the previous technology analysis. For each case the following sections should be completed:

Case 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 an ID and then can be bound to the Track Ticket when the case comes into implemenation.

Objective

A short description of the objective of the API case.

Detailed Description

A verbal description of the API case of the functional area. In this section an explanation should be given on the decisions for the specific API, based on the analysis made for the functional area. The resources involved in the specific case should be described and a clear definition of the technologies and the specifications included in the solution of the case should be given.

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

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.

Involved iMarine Resources

The section includes a sum-up of the identified resources involved into the functional area.

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 D4Science 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