Difference between revisions of "Tabular Data Service"
From Gcube Wiki
(→Architecture) |
(→Architecture) |
||
| Line 10: | Line 10: | ||
[[File:TabularDataArchitecture.png|center|800px||Tabular Data system architecture]] | [[File:TabularDataArchitecture.png|center|800px||Tabular Data system architecture]] | ||
| + | |||
| + | Tabular data system is made of three main subsystems: | ||
| + | * Tabular Data Portlet: human centric web application hosted on a gCube web portal. Allows management of the Tabular Data Service system on a per-user basis, allowing invocation of tabular data service methods and additional functionalities with external apps. | ||
| + | * Tabular Data Service: main component of the tabular data architecture. It exposes several remote interfaces covering different areas of functionalities. | ||
| + | * Data/Metadata backend: This is where raw tables data and metadata are stored and where the service keeps its management data. | ||
| + | |||
| + | The diagram shows also some of the main components that build up the service, which mainly relates to the operation management area: | ||
| + | * Operation orchestrator: The operation orchestrator is a component that receives incoming call requests from the service interface and unwinds them into a sequence of operation call. The orchestrator may enforce policies and command automatic operations/validations according to its configuration. | ||
| + | * Operation modules: Operation modules are classes that brings functionalities to the tabular data service. These functionalities can be reached directly with invocations on the Operation Interface. Operation modules can work directly with data on the Data backend or leverage the cube manager in order to create/clone tables or modify table metadata. | ||
| + | * Cube manager: The cube manager is the lowest level component of the service stack. Its main responsibilites are managing the creation/modification of tables (and their metadata) and acting as a registry for all the created tables, allowing retrieval of tables metadata. | ||
= Model = | = Model = | ||
Revision as of 15:26, 29 November 2013
Contents
Overview
Tabular Data is a system that allows to manage the lifecycle of statistical data. It's main characteristics are:
- Exposes its operation to the end user through a gCube Portlet;
- Its operations can be invoked programmatically through a gCube Web Service (smart gears);
- Provides several operations for importing/exporting from/to serveral sources/sinks;
- Provides data validations and transformations capabilities;
- Provides means for managing automatic data management processes.
Architecture
Tabular data system is made of three main subsystems:
- Tabular Data Portlet: human centric web application hosted on a gCube web portal. Allows management of the Tabular Data Service system on a per-user basis, allowing invocation of tabular data service methods and additional functionalities with external apps.
- Tabular Data Service: main component of the tabular data architecture. It exposes several remote interfaces covering different areas of functionalities.
- Data/Metadata backend: This is where raw tables data and metadata are stored and where the service keeps its management data.
The diagram shows also some of the main components that build up the service, which mainly relates to the operation management area:
- Operation orchestrator: The operation orchestrator is a component that receives incoming call requests from the service interface and unwinds them into a sequence of operation call. The orchestrator may enforce policies and command automatic operations/validations according to its configuration.
- Operation modules: Operation modules are classes that brings functionalities to the tabular data service. These functionalities can be reached directly with invocations on the Operation Interface. Operation modules can work directly with data on the Data backend or leverage the cube manager in order to create/clone tables or modify table metadata.
- Cube manager: The cube manager is the lowest level component of the service stack. Its main responsibilites are managing the creation/modification of tables (and their metadata) and acting as a registry for all the created tables, allowing retrieval of tables metadata.
Model
Service
Main Cube Manager link
