Difference between revisions of "Resource Registry Specification"
(→Less well suited Use Cases) |
|||
| Line 25: | Line 25: | ||
=== Philosophy === | === Philosophy === | ||
| − | Resource Registry has been designed and implemented to offer a high level | + | 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 === | === Architecture === | ||
| − | Resource Registry | + | 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 | *Local Buffer Data Store | ||
**Used to collect information during bridging iterations | **Used to collect information during bridging iterations | ||
| Line 43: | Line 43: | ||
**Optional use | **Optional use | ||
The persistency of this layer is provided by DataNucleus JDO. | 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: | The core logic of Resource Registry is included in the '''Resource Registry Aggregator''' component and can be summarized in the following five operations: | ||
| Line 53: | Line 52: | ||
*Manual clear of datastores | *Manual clear of datastores | ||
| − | Provider specific logic is included in repository provider implementations | + | Provider specific logic is included in repository provider implementations, providing the following properties: |
| − | *Implementations handle the actual interfacing with the remote repository | + | *Implementations handle the actual interfacing with the remote repository (e.g.: '''RRGCubeBridge''' interfaces with gCube IS) |
| − | + | ||
*Implementations are easily replaceable | *Implementations are easily replaceable | ||
**Easy adaption to different environments | **Easy adaption to different environments | ||
**Ability to change implementation in order to perform different tasks | **Ability to change implementation in order to perform different tasks | ||
| − | |||
== Deployment == | == 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. | + | 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 == | == Use Cases == | ||
| Line 69: | Line 65: | ||
=== Well suited 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 | + | 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 | *Search System | ||
*Data Sources | *Data Sources | ||
Revision as of 12:54, 4 November 2013
Contents
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 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.
