Difference between revisions of "Common Libraries Specification"

From Gcube Wiki
Jump to: navigation, search
 
(6 intermediate revisions by the same user not shown)
Line 3: Line 3:
 
|}
 
|}
  
The management facilities of the e-Infrastructure include a set of software libraries that compose to support key functions for managing hardware and software resources, as well as for interacting with managed resources.
+
The core facilities of the e-Infrastructure include a set of Java libraries that compose into solutions for managing the software and hardware of the e-Infrastructure, as well as for interacting with those resources. This document overviews such ''common libraries''.
 
+
This document overviews the range of ''common libraries'' which are available within the system as part its core resource management facilities.
+
  
 
== Overview ==
 
== Overview ==
  
Common libraries are distributed in two main sets of overlapping distributions:
+
Common libraries are grouped in three main distributions:
  
* the [[Featherweight_Stack|Featherweight Stack]] (FWS) is a set of common libraries that serve as a client-side stack for interaction with remote services managed as resources of the e-Infrastructure.  
+
* the [[Featherweight_Stack|Featherweight Stack]] (FWS) is the client stack of the e-Infrastructure, i.e. the set of libraries that allow clients to interact with its services, first and foremost the services of its enabling technologies;
  
: The featherweight nature of the stack is in the footprint of its components, which is very small in terms of code, dependencies, and overall usage requirements. Overall, the FWS simplifies the task of clients that wish to interact with the services managed by the e-Infrastructure, thereby encouraging uptake.
+
* [[SmartGears|Smartgears]] is a set of libraries that transform services and service containers into resources of the e-Infrastructure. SmartGears meets, among others, the description, publication, lifecycle management, and controlled sharing requirements which characterise hardware and software managed by the e-Infrastructure;
  
* [[SmartGears|Smartgears]] is a set of common libraries that turn Servlet-based containers and applications into gCube resources, taking care of description, publication, lifecycle, and controlled sharing requirements. SmartGears delivers these management functions in a standard manner, i.e relying only on Servlet specifications, and transparently, i.e. without demanding source-level dependencies from applications. Overall, SmartGears brings a wide range of software under the management regime of the e-Infrastructure, without requiring dedicated development. Equally, it allows the enabling technologies underneath the e-Infrastructure to evolve along standard pathways.
+
* the [https://gcore.wiki.gcube-system.org/gCube gCube Application Framework] (gCF) is a comprehensive framework to develop services for the e-Infrastructure, i.e. software written to run and be managed in it.
  
 
=== Key features ===
 
=== Key features ===
  
Collectively, the common libraries provide for:
+
Collectively, the common libraries support the following management functions:
  
; '''publication, lifetime management, and monitoring for software and hardware resources'''
+
; '''publication and discovery'''
:configuration-driven synthesis and publication of resource descriptions;
+
: periodic and event-based publication of ''resource profiles'' from initial configurations, both for hardware and software;
:detection of, publication of, and transition to key states in resource lifetime;
+
: high-level models of resources, resource queries and query results;
 +
: best-effort discovery strategies with caching and fault tolerance;
 +
: resource encryption and decryption for publication and querying;
  
; '''transparent scope management for hardware and software resources'''
+
; '''lifecycle management'''
:assignment, removal, and validation of scope for hardware resources, service endpoints, and service instances;
+
: state tracking, event-based state transitions, and remotely controlled state transitions, both for hardware and software;
:scope validation for incoming calls;
+
:proxy mechanisms for scoping of outgoing calls;
+
  
; '''transparent security management for hardware and software resources'''
+
; '''controlled sharing'''
:mechanisms for secure management of hardware and software and communication imposing nearly zero constraints
+
:resource allocation to distinguished groups of users in alignment with dynamic policies, both for hardware and software resources;
 +
:policy enforcement at deployment time (for hardware) and at call time (for software);
 +
:policy propagation in outgoing calls;
  
; '''fault management support for software resource development'''
+
; '''security management'''
:automatic assignment and handling of unrecoverable, retry-same, and retry-equivalent failure semantics;
+
:authentication and authorisation of calls to software resources.
  
; '''state management support for software resource development'''
+
; '''development support for stateful services'''
:WSRF-compliant support for access, persistence, publication, and discovery of stateful instances;
+
: WSRF-compliant support for access, persistence, publication, and discovery of service instances;
  
; '''resource publication and discovery support for software resource development'''
+
; '''plugin management'''
:high-level models of resources, queries and query results;
+
:plugin discovery, registration, unregistration for software resources;
:resource encryption and decryption for publication and querying;
+
:remote interaction support for software resource development
+
 
+
; '''high-level model of service calls'''
+
:best-effort strategies for service replica discovery and replica management;
+
:caching;
+
 
+
; '''plugin management support for software resource development'''
+
:transparent plugin discovery, registration, unregistration;
+
  
 
== Design ==
 
== Design ==
Line 55: Line 46:
 
=== Philosophy ===
 
=== Philosophy ===
  
The system delivers its library support for resource management and software resource development in two distinct forms.
+
The available common libraries reflect two different design orientations:
  
In the first form, it provides a single a single application framework (the ''gCube Application Framework'') which is tightly integrated with a particular set of runtime technologies (''Globus’ WS-Core Container''). Framework and runtime are bundled in a single distribution (''gCore'') which can be installed on hardware resources to bring them under the management regime of the system. The framework includes a set of programming abstractions that simplify significantly the development of software resources which can again be brought under the management regime of the system.  
+
* gCF is a conventional development framework that trades off development simplicity for development for flexibility. It is a library that sits at centre of software design and at the top of the software stack, providing solutions in the context of a well-defined set of technologies and in the assumption of deployment to a specific service container. The tradeoff is most advantageous for the services of the enabling technology, as it offers maximum integration between software and e-Infrastructure. Indeed, the framework is the basis upon which the vast majority of the service of the e-Infrastructure are built.  
  
In the second form, the system provides a set of libraries that specialise in different management and development support functions. The libraries that support resource management functions are independent of runtime technologies and raise no compile-time or run-time dependencies on the managed resources. The libraries that support development of software resources do so in a modular fashion, which allows partial and on-demand dependencies on system facilities.
+
* SmartGears is instead designed as a "resource enabler" for existing software and service containers, where development and deployment cannot and should not be constrained. SmartGears delivers its management functions in a standard manner, i.e relying only on Servlet specifications, and transparently, i.e. without demanding source-level dependencies from applications. Overall, SmartGears can bring a wide range of software under the management regime of the e-Infrastructure, without requiring dedicated development. At the same time, it allows new services of the enabling technology to evolve along standard pathways, embracing technologies other than those mandated by gCF.
  
The transparencies granted by the first approach have been instrumental to the rapid and consistent growth of the system, reducing significantly administration and development costs for hardware and software resources explicitly allocated to the system or developed for it. The commitment to lightweight integration mechanisms and design modularity of the second approach aligns with modern practices and brings a wider range of resources under the management regime of the system.
+
* Like SmartGears, the FWS is independent from technologies used by service implementations. The featherweight nature of the stack is in the footprint of its components, which is very small in terms of code, dependencies, and overall usage requirements. Overall, the FWS simplifies the task of clients that wish to interact with any services managed by the e-Infrastructure, gCF-based or SmartGears-based, thereby encouraging uptake.
 +
 
 +
Overall, the simplifications allowed by gCF have been instrumental to the rapid and consistent growth of the system, reducing significantly administration and development costs for hardware and software resources explicitly allocated to the system or developed for it. The commitment to lightweight integration mechanisms and design modularity in SmartGears and the FWS aligns with modern practices and brings a wider range of resources under the management regime of the e-Infrastructure.
  
 
=== Architecture ===
 
=== Architecture ===
  
The core facilities of the system rely on the following libraries:
+
The main common libraries are the following:
  
 
* '''gcf''': the gCube Application Framework, a one-stop solution for resource management support and software resource development support;
 
* '''gcf''': the gCube Application Framework, a one-stop solution for resource management support and software resource development support;
  
* '''ghn-service''': a system component that transparently manages HTTP services that run in a Servlet container;
+
* '''common-smartgears''': transparent management support for Servlet-based containers, applications, and services;
 +
 
 +
* '''common-scope''': scope handling facilities for policy management;
 +
 
 +
* '''common-validator''': annotation-based object validation facilities;
 +
 
 +
* '''common-utils-encryption''':  encryption and decryption support;
 +
 
 +
* '''common-gcore-resources''': object binding of the resource model;
 +
 
 +
* '''common-events''': annotation-based eventing support;
  
* '''ghn-client''': an extensible framework for system components that transparently manage clients of HTTP services;
+
* '''common-gcore-stubs''':client support for JAXWS-based proxies of remote gCF-based services;
  
* '''ghn-client-proxy''': a system component that transparently manages client calls to HTTP services;
+
* '''common-gcube-calls''': base layer support for outgoing calls to any infrastructural service;
  
* '''common-clients''': an API for client library development;  
+
* '''common-jaxws-calls''': JAX-WS binding of common-gcube-calls;
  
* '''common-gcore-clients''': an extension of the common-clients API for clients of gCore services;
+
* '''discovery-client''': generic API to formulate and submit queries for resource descriptions.
  
* '''common-scope''': scope handling facilities;
+
* '''ic-client''': extends discovery-client to target the Information Collector service;
  
* '''common-resources''': an implementation of the resource model;
+
* '''registry-publisher''': support to publish resource description with the Registry service;
  
* '''common-resources-publisher''': local API of remote publication services;
+
* '''common-clients''': base layer for high leve client libraries to any infrastructural service;  
  
* '''common-resources-discovery''': local API of remote discovery services;
+
* '''common-featherweight-clients''': extends common-clients for clients of standard gCF-based services;  
  
* '''common-utils-encryption''': resource encryption/decryption facilities;
+
* '''common-gcube-clients''': extends common-clients for clients of SmartGears-enabled services;  
  
 
== Deployment ==
 
== Deployment ==
 
Common Libraries are a set of facilities available as Java libraries. Therefore, there is no deployment scheme for them. They are just individually and independently co-deployed with components that need to use a particular feature that one of the offers.
 
Common Libraries are a set of facilities available as Java libraries. Therefore, there is no deployment scheme for them. They are just individually and independently co-deployed with components that need to use a particular feature that one of the offers.

Latest revision as of 10:33, 8 November 2013

The core facilities of the e-Infrastructure include a set of Java libraries that compose into solutions for managing the software and hardware of the e-Infrastructure, as well as for interacting with those resources. This document overviews such common libraries.

Overview

Common libraries are grouped in three main distributions:

  • the Featherweight Stack (FWS) is the client stack of the e-Infrastructure, i.e. the set of libraries that allow clients to interact with its services, first and foremost the services of its enabling technologies;
  • Smartgears is a set of libraries that transform services and service containers into resources of the e-Infrastructure. SmartGears meets, among others, the description, publication, lifecycle management, and controlled sharing requirements which characterise hardware and software managed by the e-Infrastructure;
  • the gCube Application Framework (gCF) is a comprehensive framework to develop services for the e-Infrastructure, i.e. software written to run and be managed in it.

Key features

Collectively, the common libraries support the following management functions:

publication and discovery
periodic and event-based publication of resource profiles from initial configurations, both for hardware and software;
high-level models of resources, resource queries and query results;
best-effort discovery strategies with caching and fault tolerance;
resource encryption and decryption for publication and querying;
lifecycle management
state tracking, event-based state transitions, and remotely controlled state transitions, both for hardware and software;
controlled sharing
resource allocation to distinguished groups of users in alignment with dynamic policies, both for hardware and software resources;
policy enforcement at deployment time (for hardware) and at call time (for software);
policy propagation in outgoing calls;
security management
authentication and authorisation of calls to software resources.
development support for stateful services
WSRF-compliant support for access, persistence, publication, and discovery of service instances;
plugin management
plugin discovery, registration, unregistration for software resources;

Design

Philosophy

The available common libraries reflect two different design orientations:

  • gCF is a conventional development framework that trades off development simplicity for development for flexibility. It is a library that sits at centre of software design and at the top of the software stack, providing solutions in the context of a well-defined set of technologies and in the assumption of deployment to a specific service container. The tradeoff is most advantageous for the services of the enabling technology, as it offers maximum integration between software and e-Infrastructure. Indeed, the framework is the basis upon which the vast majority of the service of the e-Infrastructure are built.
  • SmartGears is instead designed as a "resource enabler" for existing software and service containers, where development and deployment cannot and should not be constrained. SmartGears delivers its management functions in a standard manner, i.e relying only on Servlet specifications, and transparently, i.e. without demanding source-level dependencies from applications. Overall, SmartGears can bring a wide range of software under the management regime of the e-Infrastructure, without requiring dedicated development. At the same time, it allows new services of the enabling technology to evolve along standard pathways, embracing technologies other than those mandated by gCF.
  • Like SmartGears, the FWS is independent from technologies used by service implementations. The featherweight nature of the stack is in the footprint of its components, which is very small in terms of code, dependencies, and overall usage requirements. Overall, the FWS simplifies the task of clients that wish to interact with any services managed by the e-Infrastructure, gCF-based or SmartGears-based, thereby encouraging uptake.

Overall, the simplifications allowed by gCF have been instrumental to the rapid and consistent growth of the system, reducing significantly administration and development costs for hardware and software resources explicitly allocated to the system or developed for it. The commitment to lightweight integration mechanisms and design modularity in SmartGears and the FWS aligns with modern practices and brings a wider range of resources under the management regime of the e-Infrastructure.

Architecture

The main common libraries are the following:

  • gcf: the gCube Application Framework, a one-stop solution for resource management support and software resource development support;
  • common-smartgears: transparent management support for Servlet-based containers, applications, and services;
  • common-scope: scope handling facilities for policy management;
  • common-validator: annotation-based object validation facilities;
  • common-utils-encryption: encryption and decryption support;
  • common-gcore-resources: object binding of the resource model;
  • common-events: annotation-based eventing support;
  • common-gcore-stubs:client support for JAXWS-based proxies of remote gCF-based services;
  • common-gcube-calls: base layer support for outgoing calls to any infrastructural service;
  • common-jaxws-calls: JAX-WS binding of common-gcube-calls;
  • discovery-client: generic API to formulate and submit queries for resource descriptions.
  • ic-client: extends discovery-client to target the Information Collector service;
  • registry-publisher: support to publish resource description with the Registry service;
  • common-clients: base layer for high leve client libraries to any infrastructural service;
  • common-featherweight-clients: extends common-clients for clients of standard gCF-based services;
  • common-gcube-clients: extends common-clients for clients of SmartGears-enabled services;

Deployment

Common Libraries are a set of facilities available as Java libraries. Therefore, there is no deployment scheme for them. They are just individually and independently co-deployed with components that need to use a particular feature that one of the offers.