2011.12 WP8: iMarine Data e-Infrastructure Enabling Technology Development Monthly Activity By Task and Beneficiary
From IMarine Wiki
This activity report documents the activities performed in November and December 2011. It is integral to Activity Report of the period.
T8.1 iMarine Data e-Infrastructure Enabling-technology Development
T8.1 has moved along three main directions:
- jointly with T8.4, the task established a new methodology for distributing responsibilities among the enabling technology
- jointly with T7.1, the task started the development of tools for supporting the new building, deployment and distribution procedures
- the task started the redesign and decomposition of the gCore framework in small and independent pieces of software to support future evolutions of the enabling layer
Beside that, members of T8.1 have been actively involved in the brainstorming on the evolution of the Resource Model (T8.4) and the new mechanisms for marking the service calls using security and standard carriers (T8.2).
CNR led the brainstorming activities towards the definition/distribution of the new responsibilities within the enabling technology. The new approach is to have resource-driven interfaces instead of the current technology-driven interfaces. Each component of the enabling area will be responsible of managing a specific aspect of a resource's life cycle. According to the work done in T8.4, they will act as producers and consumers of resource's facets. Only the minimum information for identifying the resource to operate on has to be passed to the component. Then, all the remaining information will be gathered from the resource itself harvested from the Information System.
According to the direction taken on T7.1 towards the gCube Mavenization, the IS-Registry, ISPublisher and ISClient components have been modified to build with the Maven-Service-Plugin.
Finally, the ISClient has been enriched to offer queries and discovery features on Runtime Resources.
- Definition of a resource-centric methodology for redesigning the enabling layer interfaces
- ResourceClientPublisher API and ResourceDiscovery API have been partially redesigned
- Deployer and gHNManager interfaces have been partially redesigned
- IS-Registry, ISPublisher and ISClient have been fully mavenized
- ISClient has been enriched to offer queries and discovery features on Runtime Resources
FAO has implemented two components that replace functionality currently provided by gCore, though under design principles that align with directives at the WP level (see above). These are:
common-clientslibrary, a small set of service- and technology-independent abstractions for the development of client-side libraries that interact with services. This component is entirely independent from gCore and its technological stacks, and dispenses clients from exposure to scope or discovery services.
common-gcore-clientslibrary, a specialisation of
common-clientsfor classic gCore services.
First developed in the context of T9.1, where they are actively used, these libraries are fully documented in code, are under version control, and are build every night in Etics along with the Software Archives. They are to be seen as the first example of the next-generation tools for gCube, where functionality currently within gCore is recast in a set of separate libraries for modular and optional adoption.
In conjunction with T7.1, a Maven plugin for building gCube components has been implemented to easy the adoption of Maven. The plugin supports the generation of service stubs, service's GAR and Service Archive.
A new tool, MyContainer, has been developed and refined in the first two months of the project. MyContainer is a testing tool for early integration between the individual components of the service and the gCore container. It will lift well‐known techniques for unit testing in the context of integration testing.
- the evolution of scoping mechanisms is a pre-requisite for the definition of APIs for resource publication and discovery. The discussion ongoing in T8.2, and more broadly within the WP, needs to rapidly come to an indication on the dispensability of scope information from enabling interfaces.
- cross-WP discussions between WP8 and WP11 have not started yet.
- identification of key requirements for the evolution of the resource model.
- first new enabling components in replacement and evolution of functionality currently in gCore
- implementation of the Maven-Service-Plugin
- implementation of the MyContainer tool
T8.2 iMarine Data e-Infrastructure Policy-oriented Security Facilities
ENG is involved in two activities related to the evolution of the security modules integrated in gCube:
- analysis of the functional and technological requirements for Identity Federation
- analysis of the relationship between scoping and Authorization and of the possibilities to propose an Authorization model that comprises both
The first activity starts from the protocol currently used in our infrastructure, SAML 2.0. Currently SAML is used only as attribute carrier in order to carry the roles of a caller by SAML Attribute Assertions. A possible solution for Federation involves the use of SAML with the profile called SAML Web Browser SSO Profile, which includes, in addition to Attribute Assertions, also the so-called Authentication Assertions. The most popular implementation of this profile is Shibboleth. The use of such a technology could require the complete management of the SAML 2.0: as a consequence it could be necessary to upgrade the versions of some of the current gCore library (for example OpenSAML). This aspect will require further and deeper analysis.
The second activity consists in the collaboration with CNR, FAO, NKUA and CERN in order to analyze the relationship of the current scope implementation and the RBAC authorization model added to the infrastructure. Some of the aspects related to scope seem to overlap the current Authorization system: the enforcement capability based on scope is an example that could be included in the authorization domain. However there are also some other aspects which are specific of scope or role and seem not to be suitable to unification: an example is the reduction of visibility. Some possible solutions providing the integration of scope and RBAC are under investigation: one of this consists in the use of SAML assertion as scope carrier, as well as role carrier.
T8.3 Workflow Management Facilities
NKUA has been working on the analysis and design of the evolution of the PE2ng Engine. More specifically, work has been done on
- Specifying a set of execution model abstractions, which will make workflows independent of the underlying execution platform and allow PE2ng to act as a unified point of execution for high level workflows originating from all the gCube infrastructure. A set of common execution patterns, such as Master/Worker, will be supported and more are to follow according to requirements originating from other tasks and WPs.
- The formulation of a high-level workflow language, which will abstract over infrastructure and process concepts.
One other area of work is in extending the modularity and testability capacities of PE2ng software in general, however concrete results will emerge in the next periods. Last, work on supporting the persistency of execution job information is underway. This feature will allow clients to monitor their jobs regardless of changes to the state of the Workflow Engine Service instance which they have contacted during job submission.
Currently, the design phase is in progress and includes an initial set of possible abstractions. More definitive results will be available once the implementation phase starts and additional requirements are gathered from T10.2
T8.4 Resource Model
FAO, CNR and NKUA have initiated a process of requirement analysis for the evolution of the resource model. At a focused meeting at the project’s kick-off, the partners have unanimously agreed that the main requirement is for an extensible notion of resource, particularly for a resource model which is open to modular extensions at runtime by arbitrary third parties (under appropriate security restrictions of course).
Resources would share a minimal set of common properties (such as identifiers and scopes), but no further attempt would be made to statically classify their semantics and the information required to describe it. Rather, the semantics of resources would be characterised solely by the information that has been bound to them during their lifetime by various parties. This information, which we enumerate in units called facets, would be namespaced and act as configuration for a class of components that require it in order to carry out a given resource management function within the system. Functions that fall within the Enabling Layer would be re-implemented in this manner (e.g. lifetime management, deployment) ) in the context of T8.1. Additional resource management functions would also be implemented in this manner (e.g. seach profiles, activation records, runtime component configurations, etc.). An optional typing regime remains possible, by dynamic associations of facets to schemas.
Following this approach, FAO and CNR have then associated the new resource model with a design methodology in collaboration with T8.1 in which:
a) we first define the interfaces of the components that, collectively, implement a given resource management function,
b) we then describe the facet(s) which the components require to carry out of the function, and
c) we finally define a range of tools to support the publication and discovery of the required facets, striving for properties such as modularity, generality, non-invasiveness, testability, and optionality.
We have identified that, to bootstrap development under the new model and methodology, resource publication and discovery are the first resource management functions that need to be refactored, so as to enable all the others. For the time being, FAO and CNR have been working on the service interfaces and local tools required for publication, trying to address issues of retro-compatibility in the process. It has been decided to retain the existing implementation of the IS, and to relax requirements for strict validation of existing resource profiles, which allows facets to co-exist with legacy information (they would be ignored by existing clients). More concrete design and implementation steps are to follow at the next reporting periods.
FAO has coordinated the brainstorming activity on the model by identifying limits of the previous model and proposing the new ways. Then, it participated to the facets’ classifications and associated the new resource model with the new design methodology.
FAO and CNR had several conference calls and email exchanges towards the definition of the new resource model and its impact on the enabling technology.
CNR worked closely to FAO on definition of the new Resource Model, focusing on the identification of the facet's classifications and their serialization in the Information System.
As T8.1 leader and designer of the previous model, CNR drove the implementation of the design methodology for the enabling layer's interfaces and services based on the facet-oriented definition.
NKUA partecipated in the initial brainstorming phase and provided major input and requirements for the new model.