Integration and Interoperability Facilities Framework

What makes up the framework

There are several considerations towards the conceptualization and constitution of a framework. Those include:

• Methodology: The framework methodology comprises the guidelines for its development/evolution, the dictation of needed definitions, the division of the workspace into areas and the assignment of tasks to working groups that will follow the defined road-map
• Principles: Those are necessary both for defining / building the framework but also for using it and evolving it. The principles make up the basis on which the framework builds and are conducted by the ultimate goals targeted by the framework constitution.
• Technologies or techniques employed by the framework: Those include the standard technologies adopted by the framework and the techniques it affiliates in handling common framework issues
• Toolkit(s) that are offered as part of this framework: Those can offer commonly used functionality based on the framework principles, to spare those that extend the framework from re-implementing the same tools and to ensure the sound use of the defined techniques. Another usage example of framework toolkits, would be in the cases of facilitating the interaction with APIs that don't dispose well defined data exchange formats
• Procedures for using, extending, revising this framework: The need for determining those procedures is undisputed to reserve the entity of the framework and its evolution

Framework Layers

The analysis of the options and needs of the infrastructure lead to strategic decisions for the architecture and the design of the Integration and Interoperability framework. Those include the following:

• There is little value and large cost in merging the existing Application Services Layer components with the Client Libraries. The existing implementation of ASL is aimed towards Portal and HTTP API development servicing, making functional assumptions (i.e. closer to application than plain API exposure), aggregating access to multiple services and offering higher complexity functionalities. Development in ASL is guieded by the principles of completely hiding gCube implementations from the applicaction level and provides and internal session mechanism which would require a transition from stateless to statefull operations within all Client Libraries.
• There is no value in aligning on the basis of interoperability the existing WSRF service interfaces, as these are not expected to be exploited directly by others.
• As a result, a framework of three layers has been conceived and established within the WP and working areas have been defined for these. The layers that make up the framework are the following:
  • Client Libraries: This layer focuses on a subset of the client libraries found within the system, those that mediate access to some of the services.
  • ASL: This layer offers a front end to services and higher level functionalities.
  • HTTP Front End: Falling under large functional areas that comply to standards

The framework of "layers" is depicted in the image below:

Framework Specifications

Specifications for each topic analyzed in the context of Integration and Interoperability Facilities Framework Definition can be found below:

• Client Libraries Framework Specification
• Application Service Layer Framework Specification
• HTTP API Framework Specification
• WSRF API Framework Specification