2012.01 WP11: Data e-Infrastructures Integration and Interoperability Facilities Development Monthly Activity By Task and Beneficiary
From IMarine Wiki
This WP11 Activity Report described the activities performed in January 2012 by Beneficiary and Task. It is part of January 2012 Activity Report.
T11.1 Application Programming Interfaces Framework Definition
During the third period, the task completed the definition, evaluation and fine-tuning of the methodology that will lead the process of development in all the work package tasks.
A concrete plan for the the production of the D11.1 has been presented and evaluated by WP partners. The process of development has been recorded and established in wiki pages through which a clear path of the WP steps is designated. Two approaches determine the upcoming tasks and are launched in parallel. In the context of this methodology, distinct framework layers and functional areas have been identified and working groups in charge for each subdivision of the work space have been defined.
The work done on the definition of the architecture of Integration and Interoperability Layer, has imposed the need for the evolution not only of the current Application Service Layer but for the client libraries of the system also. To this end, a working group has been established to lead the definition of the domains and their directions towards the creation of interoperable interfaces targeted by the WP.
Finally, there has been progress on the investigation of the evolution of the HTTP interface for searching, to allow the provision of advanced data discovery facilities in gCube. The needs for the extensions identified are further analysed as part of the T11.3.
After an analysis of the policies needed and the options within the objectives of the task, it was decided that
- there is little value and large cost in merging the existing Application Services Layer with the 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 of the work in the WP, a framework of three layers is conceived and working areas have been defined for these.
- There is a slight postponing of the activities of the WP, however along the new conceptualization of the WP work, which is compliant with initial objectives this better suits the work of the whole project, as alignment with other WPs activities is improved.
- Establishment of wiki pages that will constitute the skeleton of the D11.1.
- Definition of a framework of three layers for the system and composition of working groups for the identification of principles.
T11.2 Data Management APIs
FAO continues to prototype client-side solutions to support the framework for local Java APIs, in agreement with WP roadmap. Two new solutions have been developed and are already under source revision. The first, common-scope, deals with transparent scope propagation within JVM (based on inheritable thread locals) and flexible scope map configuration (based on classpath scanning). The second, common-ghn-client, addresses issues of transparent interception of client calls over HTTP, particularly with regard to scope injection. The work is framed by a more general notion of client-container and mechanisms to bootstrap it without requiring explicit dependencies. Call interception relies on an embedded HTPP proxy and transparent proxying of clients sockets, with fallback strategies based on uri re-writing and system properties. In barebone JVMs, i.e. for pure clients, the client container is bootstrapped by Java instrumentation agents, at JVM startup. In servlet container, i.e. for services that acts as clients of services further downstream, the client container is bootstrapped by service listeners.
FAO has measured these mechanisms against a range of common HTTP APIs, from java.net URLConnections and Apache's HTTPClient (low-level), to Restlet, Jersey, and RestEasy. In some cases (java.net, Jersey over anything, Restlet over anything, and RestEasy over java.net), the goals are reached at 0 dependencies (full transparency). In others, HTTPClient and ReastEasy over HTTPClient, minimal dependencies are required (calls for uri rewriting).
- common-scope prototype
- common-ghn-client prototype
T11.3 Data Consumption APIs
In the Data Transformation area the future case has been examined of performing all appropriate transformations to obtain desired data, based on a given representation. In the context of this analysis, the investigation focused on the OAI-ORE specification for handling the aggregations of resources.
Moreover, an extension of the API offered from the Application Service Layer has been designed, in the context of the exploitation of gCube Search services from data mining facilities. The extension targets the provision of a more generalised and flexible way to exploit the facilities provided. The expansion will be mirrored in both JAVA and HTTP APIs that are exposed from this layer of the infrastructure to support the respective access to functionality in multiple ways.
Finally NKUA continues the investigation of OGC WCS, WCPS and Catalog specifications for designing the next generation Information Retrieval Services that interacts with such services available in the ecosystem.
Concerning the new functionalities in the infrastructure that will be provided by FORTH it is generally agreed to follow the main principles (those driven from D4S, D4S II) and the proposed methodology for producing the APIs.
A specification of a possible HTTP API of the Exploratory Search Services is being under analysis and designation.