Difference between revisions of "0.6 Release Notes"

From GCube System
Jump to: navigation, search
(Changes Related to Services)
(Changes Related to Services)
Line 19: Line 19:
  
 
:* ''support for service plugins''.
 
:* ''support for service plugins''.
:: gCF now adds programming abstractions for the design of ''pluggable services'', i.e. service that can be dynamically extended with code that is packaged and deployed as the payload of ''service plugins''. The abstractions offer transparencies for the management, description, and configuration of service plugins and are interfaced by the <code>Deployer</code> service for their deployment.
+
:: gCF now includes programming abstractions for the design of ''pluggable services'', i.e. services that can be dynamically extended with code that is packaged and deployed as the payload of ''service plugins''. The available abstractions offer transparencies for the management, description, and configuration of service plugins and are relied upon by the <code>Deployer</code> service for their deployment. A Plugin Manager takes care of plugin registration, validation, and local persistence, and it acts as producer of registration events for a range of subscribers within service implementations. A Plugin Context characterises the entry point to the code in the plugin and transparently exposes information which is common to all plugins, including their profiles, arbitrary descriptive properties for plugin discovery, and type mappings required to deserialise plugin components that need to be exchanged over the wire. As usual, service developers extend Plugin Managers and Plugin Context to both extend and tailor their functionality to the plugins of their own services.
  
 
:* ''support for synchronous publication''.
 
:* ''support for synchronous publication''.
Line 25: Line 25:
  
 
:* ''support for call authorisation''.
 
:* ''support for call authorisation''.
:: All security managers in gCF now intercept incoming gCube calls and forward them to a configurable local authorisation engine for the enforcement of service policies in a secure infrastructure. The policies are remotely defined but locally cached, first at service startup (as a pre-condition to the usability of the service) and then whenever they change.
+
:: gCore now intercepts incoming gCube calls and forwards them to a local authorisation engine for the enforcement of service policies in a secure infrastructure. Authorisation policies are remotely defined but locally cached, first at service startup - as a pre-condition to the usability of the service - and then whenever they change. The mediation between the container (which intercepts the calls) and the engine (which authorises them) is taken up by security managers, which thus now offer support for both authorisation and authentication. The current engine that currently ships with gCore is applies simple combinations of a fixed number of policies of immediate relevance to the infrastructure.

Revision as of 10:01, 28 October 2009

gCore 0.6 introduces the following changes:

Changes Related to the gHN

  • new versions of Local Services and Libraries. Most noticeably:
  • the ResultSet service, with optional [SSL support http://add.link].
  • the Deployer service, with support for plugin deployment and activation. In the version of the service included in this distribution, the deployment of pluggable services implies the deployment of all their plugins from the SoftwareRepository service.
  • the Delegation service, with support for periodic delegation of service credentials. In the version of the service included in this distribution the credentials of the local gHN are used in place of service credentials to identify services as operating from trusted gHNs.
  • the ISPublisher and Collector-stubs libraries, with support for synchronous publication.
  • the SoftwareRepository-stubs library, with support for plugin download.
  • the Resources library, with support for plugin profiles. Associated changes can be found in service.xsd and runninginstance.xsd under $GLOBUS_LOCATION/share/schema/gcube/common/core/profiles.
  • the GCubeProvider library, with support for WS-Notification interfaces.
  • the new Security library, with support for authentication and authorisation of gCube calls.
  • two new scripts in $GLOBUS_LOCATION/bin, gcore-start-container-debug and gcore-start-container-profile, to start the gHN in debug and profiling mode, respectively. See also the Primer for detailed usage instructions.

Changes Related to Services

  • support for service plugins.
gCF now includes programming abstractions for the design of pluggable services, i.e. services that can be dynamically extended with code that is packaged and deployed as the payload of service plugins. The available abstractions offer transparencies for the management, description, and configuration of service plugins and are relied upon by the Deployer service for their deployment. A Plugin Manager takes care of plugin registration, validation, and local persistence, and it acts as producer of registration events for a range of subscribers within service implementations. A Plugin Context characterises the entry point to the code in the plugin and transparently exposes information which is common to all plugins, including their profiles, arbitrary descriptive properties for plugin discovery, and type mappings required to deserialise plugin components that need to be exchanged over the wire. As usual, service developers extend Plugin Managers and Plugin Context to both extend and tailor their functionality to the plugins of their own services.
  • support for synchronous publication.
Resource publication can now occur in synchronous fashion, depending on the choice of interfaces used for publication. Publications performed by gCF on behalf of service developers (e.g. for WS-Resources) can be configured to occur either synchronously or asynchronously.
  • support for call authorisation.
gCore now intercepts incoming gCube calls and forwards them to a local authorisation engine for the enforcement of service policies in a secure infrastructure. Authorisation policies are remotely defined but locally cached, first at service startup - as a pre-condition to the usability of the service - and then whenever they change. The mediation between the container (which intercepts the calls) and the engine (which authorises them) is taken up by security managers, which thus now offer support for both authorisation and authentication. The current engine that currently ships with gCore is applies simple combinations of a fixed number of policies of immediate relevance to the infrastructure.