Difference between revisions of "Resource Registry Specification"

Revision as of 12:38, 1 November 2013

Overview

Resource Registry is a resource aggregating and management component of the information related to the resources that exist on Information System (IS).

This document outlines the design rationale, key features, and high-level architecture, the options for their deployment and as well some use cases.

Key features

Resource aggregation of the resources available in the infrastructure

Hosting Nodes, PE2ng Execution Nodes, Workflow Engine Endpoints, Datasources, Search Fields, Data Collections etc

Data management abstraction

Through model entities and predefined queries

Local image of the resources

Access and management of resources is done locally and synchronized with the IS periodically

Search system facilitation

Update of the entities of the model (Fields Searchables, Presentables)

Highly configurable

Datasource types, Datasource services, model entities etc can be configured

Environment independent

Resource Registry can be configured to operate outside gCore

Pluggable

Designed to support extensions through plugins

Design

Philosophy

Resource Registry has been designed and implemented to offer a high level of abstraction and quality functionalities in management of the resources that are available in the infrastructure by offering simple and powerful ways to manage data and perform complicated task, and by optimizing the network communication with the IS though periodical synchronizations

Architecture

Resource Registry basically is a library on top of a level of datastores which holds the actual data. The datastore layer is what the user sees as a state of the Information System and where the user performs her management operations on these data. Periodically, Resource Registry contacts the IS in order to (i) get new data (Retrieve phase) and (ii) apply the local changes so they are visible to other components (Update phase). This operation is the basic working cycle of Resource Registry and is called Bridging Iteration. The datastores layer is consisted of the following different (DataNucleus) data stores:

• Local Buffer Data Store
  • Used to collect information during bridging iterations
  • Internal use
  • Current implementation: Derby
• Local Data Store
  • Contains the aggregated image produced by the latest iteration
  • Guarantees consistent data
  • Current implementation: Derby
• Remote Data Store
  • Used whenever the remote repository can be modeled as a DataNucleus data store
  • E.g. LDAP
  • Optional use

The persistency of this layer is provided by DataNucleus JDO.

The core logic of Resource Registry is included in the Resource Registry Aggregator component and can be summarized in the following five operations:

• Environment initialization
• Bridging iterations execution
• Data store replication handling and coarse grained locking
• Graceful shutdown
• Automatic clear of datastores on error
• Manual clear of datastores

Provider specific logic is included in repository provider implementations

• Implementations handle the actual interfacing with the remote repository
• E.g.: RRGCubeBridge interfaces with gCube IS
• Implementations are easily replaceable
  • Easy adaption to different environments
  • Ability to change implementation in order to perform different tasks

Deployment

Resource Registry is 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 them offers.

Use Cases

Well suited use cases

Resource Registry is ideal for components that need continuous communication with the Information System and/or want to exploit he management abstraction of the resources in order to perform complicated tasks easily. The local retrieval of the resources needed minimizes the network communication since all the operations are done locally and are synchronized periodically. Currently the following components are using Resource Registry:

• Search System
• Data Sources
• ASL
• Search Manager portlet
• PE2ng
• Workflow Engine
• Execution Engine
• gCube Data Transformation Service
• Data Access

Less well suited use Cases

In case that only a few communications with the Information System are needed and/or the operations are simple, using the Resource Registry might be an overhead in terms of performance, because of the synchronisation and management operations that are performed internally are not needed.