Difference between revisions of "GCube Integration and Interoperability Facilities Development Methodology"

Revision as of 17:18, 6 April 2012

The methodology presented in this page has been defined to drive the development of the gCube Integration and Interoperability Facilities.

Objective

The objective of this area is to define and record the procedures followed towards the development of the set of facilities targeted from the WP. These facilities will manifest sets of Application Programming Interfaces (APIs) and of Interoperability cases. The described activities target the establishment of the definition of the integration and interoperability frameworks of gCube. They will lead to the identification and implementation of standards at the boundaries of services and the entire infrastructure for interactions with its elements or its entity. The main focus is the provision of programmatic APIs that enable integration and interoperability, for and beyond the specifications adopted.

The perspective of the workpackage faces interoperability at both a top-down and a bottom-up approach:

• bottom-up approach: definition of a framework in terms of principles, architecture and procedures, to which the implementing programmable APIs will comply

The tasks are as follows:

1. Analysis of APIs at infrastructure layer boundaries, i.e. external access points, internal services, libraries etc.
2. Identification of opportunities and needs for: homogenization, consistency, standards compliance, ease of use etc.
3. Aggregation of findings into a framework

• top-down approach: API-domains (functionality + protocol) are the main vehicles of the top-down approach. The technologically concrete outcome of each case analysis will be the definition of the specifications of the resources interaction, that will drive implementations and support of the programmable APIs.

The tasks in this path are as follows:

1. Definition of Functional Categories
2. Identification of Functional Areas in each Functional Category.
3. Identification of Integration and Interoperability Cases in each functional areas.
4. Evaluation of Integration and Interoperability Cases (protocols, use cases, needs, interoperability flows, SWOT analysis, prioritization etc) - at this point the analysis must meet the Bottom Up approach.
5. Conclusions and selection of implementation path

In the bottom-up approach the main direction is defined towards the removal of internal boundaries and dependencies to specific technologies. In the top-down approach the options will be identified towards the adoption of standards and the cases per domain will be analyzed in a cost/benefit manner. The two approaches are launched sequentially. The principles of the framework on which the well organized set of APIs will be based are being analyzed while the API cases that are oriented towards main functional areas are being investigated on the basis of those principles. The most important concern within the WP objectives is to adopt higher level standards and to build interoperable APIs. The two paths, meet at the the point of consumption of lower level artifacts via their API for the satisfaction of functional area needs, and they mutually affect each other, as the top-down approach will drive needs from APIs while the bottom-up approach will promote specific cases over alternative ones and will raise the opportunities for more cases.

Not all tasks mentioned above belong to the Integration and Interoperability Framework Definition, whoever there is a strong relationship according to this two-direction approach.

Bottom-Up Approach: Framework Evolution Roadmap in Brief

• Conceptualization of "Framework"
• Activity partitioning: split work in layers and functional areas + assign work to WGs
• Activity partitioning outcome into framework - The Framework definition : aggregation of findings in several areas
• Facilities development: APIs (outside this activity)
• Framework evolution: as a response to feedback and RTD WP progress

The roadmap defines the steps through which the designation and development of integration facilities will lead to the framework definition and adoption. The first tasks include the conceptualization of the framework and its elements and the assignement of tasks for analysis to working groups. The next step will be the definition of the principles governing the various framework elements. In the third stage, the aggregation of findings in several areas will gradually lead to the formalization of the framework definition in terms of procedures and technologies. The definition of technologies that form integral part of the framework will lead to the formalisation of framework toolkits. After each stage indicated by the roadmap completes, an interaction with other RTD WPs is required. Through this interaction an assessment of developments will be performed for refining and extending the initial concepts and integrate the finalization of framework definition.

The full plan of the activity can be found here.

Framework Conceptualization

In this section, the structure of the analysis that will lead to the framework conceptualization is briefly described. In particular, the following matters need to be defined:

Principles

Definition of the principles and policies of Integration and Interoperability, identifying both the roadmap and the primary specifications (protocols) to be covered by the various facilities and tasks of the WP. Define the main rules and guidelines through which the compliant APIs will be hiding the complexity of the distributed infrastructure and will be dealing with common functionality.

Architecture

Definition of a formal architectural view of Integration and Interoperability Layer, as an evolution of the current Application Service Layer.

Technologies

Technologies that will be used and will further define the investigation domains of the API cases.

Adopted specifications

(to evolve continuously)

Components following the definition

Reference to components following the definition of the framework

The definition of the framework is conducted in the "Integration and Interoperability Facilities Framework" section.

Top-Down Approach: Functional Categories and Areas Definition

The resources offered by the infrastructure are exposed through functionality that falls into several functional categories. The primary ones are Data Management and Data Consumption, however more can be identified in the vast landscape of a D4Science ecosystem.

The main objective is the organisation of the design and implementation of the APIs that allow access to the system resources and their binding to standards specific to each area. Each functional category is divided into more targeted functional areas for which a number of cases will be identified. The cases relate to the provision of multi-protocol APIs (e.g. Java, REST, SOAP, depending on the need and relevance) and related implementation components for easy consumption for a number of facilities that fall into the area. An analysis of the resources involved is being performed per functional area. Gathering of resources is an essential part of the functional areas, especially as a result of their evolution to more concrete cases and ultimately to solutions. Resources are the entities that at the bottom line have to become interoperable. As such the achievement of interoperability ultimately leads to resource specifications that capture policies and interfaces. An examination of the overall infrastructure's capabilities and the requirements for the exploitation by other resources will lead to the definition of the given options and needs. The analysis of the technological solutions will lead to the designation of API specific case analysis and the creation of bindings to specific protocols and standards.

Cases are linked in several ways:

• in thematically related groups that fall under the same functional category
• in hierarchies that move from protocol/technology to resource interoperability specifications
• in dependencies nets that guarantee that a case will survive in the complex e-Infrastructures environment

The functional categories identified are the following:

• Data Management
• Data Consumption
• Computation Consumption (tentative)
• Infrastructure Management (tentative)

For each functional area, a number of cases can be identified as candidates for fulfilling its requirements. This creates a 3-level hierarchy: Functional Category -> Functional Area -> API Case. A concrete example of this hierarchy is the following:

Data Consumption -> Generic Information Retrieval -> Open Search

Functional Area Cases Identification Template

In order to facilitate the analysis of the functional areas, a template has been constructed. This template foresees the description analysis of a functional area, with the inclusion of one or more cases that satisfy the respective functionality. More info can be found on the template.

The template can be located here here.