Difference between revisions of "Common Libraries Specification"

Revision as of 16:17, 7 November 2013

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.

This document overviews the range of common libraries which are available within the system as part its core resource management facilities.

Overview

Common libraries are distributed in two main sets of overlapping distributions:

• the 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 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 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.

Key features

Collectively, the common libraries provide for:

publication, lifetime management, and monitoring for software and hardware resources

configuration-driven synthesis and publication of resource descriptions;

detection of, publication of, and transition to key states in resource lifetime;

transparent scope management for hardware and software resources

assignment, removal, and validation of scope for hardware resources, service endpoints, and service instances;

scope validation for incoming calls;

proxy mechanisms for scoping of outgoing calls;

transparent security management for hardware and software resources

mechanisms for secure management of hardware and software and communication imposing nearly zero constraints

fault management support for software resource development

automatic assignment and handling of unrecoverable, retry-same, and retry-equivalent failure semantics;

state management support for software resource development

WSRF-compliant support for access, persistence, publication, and discovery of stateful instances;

resource publication and discovery support for software resource development

high-level models of resources, queries and query results;

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

Philosophy

The system delivers its library support for resource management and software resource development in two distinct forms.

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.

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.

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.

Architecture

The core facilities of the system rely on the following libraries:

• 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;

• ghn-client: an extensible framework for system components that transparently manage clients of HTTP services;

• ghn-client-proxy: a system component that transparently manages client calls to HTTP services;

• common-clients: an API for client library development;

• common-gcore-clients: an extension of the common-clients API for clients of gCore services;

• common-scope: scope handling facilities;

• common-resources: an implementation of the resource model;

• common-resources-publisher: local API of remote publication services;

• common-resources-discovery: local API of remote discovery services;

• common-utils-encryption: resource encryption/decryption facilities;

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.