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
NKUA Activities
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 production of the D11.1 has been presented and evaluated by all 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.
- As a corrective action a framework of three layers is considered within the WP objectives and working groups have been defined for the driving of the respective goals.
- 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 Activities
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).
None.
- common-scope prototype
- common-ghn-client prototype
T11.3 Data Consumption APIs
NKUA Activities
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.
none
none
FORTH Activities
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.
None
None
