Difference between revisions of "0.6 Release Notes"
From GCube System
(→Changes Related to Services) |
(→Changes Related to Services) |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 5: | Line 5: | ||
:* ''new versions of Local Services and Libraries''. Most noticeably: | :* ''new versions of Local Services and Libraries''. Most noticeably: | ||
| − | ::* the <code>ResultSet</code> service, with optional [ | + | ::* the <code>ResultSet</code> service, with optional [https://technical.wiki.d4science.research-infrastructures.eu/documentation/index.php/GCube_ResultSet_(gRS)#ResultSet_Security SSL support]. |
::* the <code>Deployer</code> 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 <code>SoftwareRepository</code> service. | ::* the <code>Deployer</code> 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 <code>SoftwareRepository</code> service. | ||
::* the <code>Delegation</code> 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 <code>Delegation</code> 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. | ||
| Line 15: | Line 15: | ||
:* ''debugging and profiling launch modes''. | :* ''debugging and profiling launch modes''. | ||
| − | :: Depending on two new launch scripts, the gHN can now be launched with settings that allow the use of debuggers and profilers. See | + | :: Depending on two new launch scripts, the gHN can now be launched with settings that allow the use of debuggers and profilers. See the [[Migration_Guidelines_from_0.5.1_to_0.6#Changes_Related_to_Configuration_and_Use_of_the_gHN|migration guidelines]] for further information. |
====Changes Related to Services ==== | ====Changes Related to Services ==== | ||
:* ''support for service plugins''. | :* ''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 <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 local registration events. 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, the descriptive properties whereby they can be discovered, and the type mappings that are required to deserialise their components over the wire. As usual, service developers extend Plugin Managers and Plugin Contexts to extend and tailor their functionality to the plugins of their own services. | + | :: 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 local registration events. 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, the descriptive properties whereby they can be discovered, and the type mappings that are required to deserialise their components over the wire. As usual, service developers extend Plugin Managers and Plugin Contexts to extend and tailor their functionality to the plugins of their own services. See the [[Migration_Guidelines_from_0.5.1_to_0.6#Changes_Related_to_Configuration_and_Use_of_the_gHN|migration guidelines]] for further information. |
:* ''support for synchronous publication''. | :* ''support for synchronous publication''. | ||
| − | :: Resource publication can now occur in synchronous or asynchronous fashion, depending on the choice of publication interfaces used. The generic interface <code>ISPublisher</code> abstracts over synchronous and asynchronous implementations, while <code>ISSyncPublisher</code> and <code>ISAsyncPublisher</code> have specialised implementations. An asynchronous implementation is bound by default to the generic <code>ISPublisher</code> interface. Publications performed by gCF on behalf of service developers (e.g. for WS-Resources) can be configured to occur either synchronously or asynchronously. | + | :: Resource publication can now occur in synchronous or asynchronous fashion, depending on the choice of publication interfaces used. The generic interface <code>ISPublisher</code> abstracts over synchronous and asynchronous implementations, while <code>ISSyncPublisher</code> and <code>ISAsyncPublisher</code> have specialised implementations. An asynchronous implementation is bound by default to the generic <code>ISPublisher</code> interface. Publications performed by gCF on behalf of service developers (e.g. for WS-Resources) can be configured to occur either synchronously or asynchronously. See the [[Migration_Guidelines_from_0.5.1_to_0.6#Changes_Related_to_Configuration_and_Use_of_the_gHN|migration guidelines]] for further information. |
:* ''support for call authorisation''. | :* ''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 engine that currently ships with gCore serves as a proof-of-concepts as it applies simple combinations of a fixed number of policies of immediate relevance to the infrastructure. More sophisticated engines and full integration with remote services within the infrastructure are planned for future work. | :: 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 engine that currently ships with gCore serves as a proof-of-concepts as it applies simple combinations of a fixed number of policies of immediate relevance to the infrastructure. More sophisticated engines and full integration with remote services within the infrastructure are planned for future work. | ||
| + | |||
| + | :* ''support for handler lifetime and event management''. | ||
| + | :: The lifetime of handlers can now may be explicitly modelled in terms of a number of phases, where handlers change state moving from phase to phase. For example, the handler may be in a running state, it may have completed successfully, it may have failed, or it may be temporarily suspended. The Handler Framework now allows states to be modelled explicitly and takes care of managing state transitions, including validation and state change notifications. It also supports the management of subscriptions and notifications for arbitrary events, not only lifetime events. See the [[Migration_Guidelines_from_0.5.1_to_0.6#Changes_Related_to_Configuration_and_Use_of_the_gHN|migration guidelines]] for further information. | ||
| + | |||
| + | ====Changes Related to the Documentation ==== | ||
| + | |||
| + | :* ''new/revised sections in the Developer's Guide''. | ||
| + | :: Work on the Developer's Guide progresses with an enriched section on [[Contexts|context components]] and a new, extensive section on the [[The_Handler_Framework|Handler Framework]]. | ||
Latest revision as of 14:06, 30 October 2009
gCore 0.6 introduces the following changes:
Changes Related to the gHN
- new versions of Local Services and Libraries. Most noticeably:
- the
ResultSetservice, with optional SSL support. - the
Deployerservice, 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 theSoftwareRepositoryservice. - the
Delegationservice, 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
ISPublisherandCollector-stubslibraries, with support for synchronous publication. - the
SoftwareRepository-stubslibrary, with support for plugin download. - the
Resourceslibrary, with support for plugin profiles. Associated changes can be found inservice.xsdandrunninginstance.xsdunder$GLOBUS_LOCATION/share/schema/gcube/common/core/profiles. - the
GCubeProviderlibrary, with support for WS-Notification interfaces. - the new
Securitylibrary, with support for authentication and authorisation of gCube calls.
- the
- debugging and profiling launch modes.
- Depending on two new launch scripts, the gHN can now be launched with settings that allow the use of debuggers and profilers. See the migration guidelines for further information.
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
Deployerservice for their deployment. A Plugin Manager takes care of plugin registration, validation, and local persistence, and it acts as producer of local registration events. 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, the descriptive properties whereby they can be discovered, and the type mappings that are required to deserialise their components over the wire. As usual, service developers extend Plugin Managers and Plugin Contexts to extend and tailor their functionality to the plugins of their own services. See the migration guidelines for further information.
- support for synchronous publication.
- Resource publication can now occur in synchronous or asynchronous fashion, depending on the choice of publication interfaces used. The generic interface
ISPublisherabstracts over synchronous and asynchronous implementations, whileISSyncPublisherandISAsyncPublisherhave specialised implementations. An asynchronous implementation is bound by default to the genericISPublisherinterface. Publications performed by gCF on behalf of service developers (e.g. for WS-Resources) can be configured to occur either synchronously or asynchronously. See the migration guidelines for further information.
- 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 engine that currently ships with gCore serves as a proof-of-concepts as it applies simple combinations of a fixed number of policies of immediate relevance to the infrastructure. More sophisticated engines and full integration with remote services within the infrastructure are planned for future work.
- support for handler lifetime and event management.
- The lifetime of handlers can now may be explicitly modelled in terms of a number of phases, where handlers change state moving from phase to phase. For example, the handler may be in a running state, it may have completed successfully, it may have failed, or it may be temporarily suspended. The Handler Framework now allows states to be modelled explicitly and takes care of managing state transitions, including validation and state change notifications. It also supports the management of subscriptions and notifications for arbitrary events, not only lifetime events. See the migration guidelines for further information.
Changes Related to the Documentation
- new/revised sections in the Developer's Guide.
- Work on the Developer's Guide progresses with an enriched section on context components and a new, extensive section on the Handler Framework.
