Difference between revisions of "Resource Registry Specification"

Latest revision as of 14:18, 4 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 abstraction and quality functionalities for the management of resources that are available in the infrastructure by offering simple and powerful ways to manage data and perform complicated tasks. It also provides network communication optimization with the IS through periodical synchronizations.

Architecture

Resource Registry is basically 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 management operations on 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 manages the following data stores (DataNucleus):

• 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 interaction between Resource Registry - Local (Buffer) Data Stores and Information System (IS) is depicted in the picture bellow:

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, providing the following properties:

• 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 a set of 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 the management abstraction of the resources in order to perform complicated tasks easily. The local retrieval of the application requried resources minimizes the network communication since all the operations are done locally and are synchronized periodically. Several components are currently exploiting Resource Registry facilities:

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