Difference between revisions of "Common Libraries Specification"

From Gcube Wiki
Jump to: navigation, search
(→‎Architecture)
Line 3: Line 3:
 
|}
 
|}
  
 +
A rich set of software libraries supports key management functions over software and hardware resources, as well the development of software resources that integrate or interface the system.
 +
 +
This document overviews the range of software libraries that are available within the system as part its core facilities.
  
 
== Overview ==
 
== Overview ==
  
−
A brief overview of the subsystem should be here. It should include the key features.  
+
Core facilities such as publication and lifetime management of software and hardware resources are in part implemented locally to the resources, via software libraries that interact with remote services on behalf of the resources.  
 +
 
 +
Software libraries provide also tooling that simplifies and homogenises the development of components that are part of the system, extend the system, or interface the system.
  
 
=== Key features ===
 
=== Key features ===
  
−
;Lightweight integration mechanisms with existing technologies
+
Collectively, the core libraries provide for:
−
:...
+
  
−
;Extensible Software Model
+
; '''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;
  
−
;Different level of engagements
+
; '''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;
  
−
;Encryption/decryption of resources
+
; '''transparent security management for hardware and software resources'''
−
:...
+
:TODO
 +
 
 +
; '''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 ==
 
== Design ==
  
 
=== Philosophy ===
 
=== Philosophy ===
−
This is the rationale behind the design. An example will be provided.  
+
 
 +
Then 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 ===
 
=== Architecture ===
−
* '''common-ghn-client''': a client container that discovers and manages an open-ended set of facilities on client nodes (we call them client services)
+
 
−
* '''common-ghn-client-proxy''': key client service in the client container. installs an embedded HTTP proxy that intercepts client calls in full transparency from client code
+
The core facilities of the system rely on the following libraries:
−
* '''common-ghn-service''': management facilities to manage HTTP services that run in a servlet container in full transparency from the services themselves
+
 
−
* '''common-clients''': base framework for client library development, gCore-independent
+
* '''gcf''': the gCube Application Framework, a one-stop solution for resource management support and software resource development support;
−
* '''common-gcore-clients''': gCore-bridge for common-clients  
+
 
−
* '''common-scope''': scope and service map handling facilities  
+
* '''ghn-service''': a system component that transparently manages HTTP services that run in a Servlet container;
−
* '''common-resource''': reference implementation of the new Resource Model
+
 
−
* '''common-resource-publisher''': publishing of gCube resources according to the new Resource Model 
+
* '''ghn-client''': an extensible framework for system components that transparently manage clients of HTTP services;
−
* '''common-resource-access''': discovery of gCube resources according to the new Resource Model
+
 
−
* '''common-utils-encryption''': encryption/decryption utilities to be exploited in the common-resources
+
* '''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-publish''': local API of remote publication services;
 +
 
 +
* '''common-resources-query''': local API of remote discovery services;
 +
 
 +
* '''common-resources-encryption''': resource encryption/decryption facilities;
  
 
== Deployment ==
 
== Deployment ==
−
Usually, a subsystem consists of a number of number of components. This section describes the setting governing components deployment, e.g. the hardware components where software components are expected to be deployed. In particular, two deployment scenarios should be discussed, i.e. Large deployment and Small deployment if appropriate. If it not appropriate, one deployment diagram has to be produced.
 
  
 
=== Large deployment ===
 
=== Large deployment ===
  
−
A deployment diagram suggesting the deployment schema that maximizes scalability should be described here.
 
  
 
=== Small deployment ===
 
=== Small deployment ===
  
−
A deployment diagram suggesting the "minimal" deployment schema should be described here.
 
  
 
== Use Cases ==
 
== Use Cases ==
−
The subsystem has been conceived to support a number of use cases moreover it will be used to serve a number of scenarios. This area will collect these "success stories".
 
  
 
=== Well suited Use Cases ===
 
=== Well suited Use Cases ===
  
−
Describe here scenarios where the subsystem proves to outperform other approaches.
 
  
 
=== Less well suited Use Cases ===
 
=== Less well suited Use Cases ===
−
 
−
Describe here scenarios where the subsystem partially satisfied the expectations.
 

Revision as of 16:09, 1 March 2012

A rich set of software libraries supports key management functions over software and hardware resources, as well the development of software resources that integrate or interface the system.

This document overviews the range of software libraries that are available within the system as part its core facilities.

Overview

Core facilities such as publication and lifetime management of software and hardware resources are in part implemented locally to the resources, via software libraries that interact with remote services on behalf of the resources.

Software libraries provide also tooling that simplifies and homogenises the development of components that are part of the system, extend the system, or interface the system.

Key features

Collectively, the core 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
TODO
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

Then 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-publish: local API of remote publication services;
  • common-resources-query: local API of remote discovery services;
  • common-resources-encryption: resource encryption/decryption facilities;

Deployment

Large deployment

Small deployment

Use Cases

Well suited Use Cases

Less well suited Use Cases

Retrieved from "https://gcube.wiki.gcube-system.org/index.php?title=Common_Libraries_Specification&oldid=13659"