Difference between revisions of "Tabular Data Service"
From Gcube Wiki
(→Overview) |
m |
||
| (19 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | = Overview = | + | {| align="right" |
| − | Tabular Data is a system that allows to manage the lifecycle of | + | ||__TOC__ |
| + | |} | ||
| + | |||
| + | Part of the [[Data Access and Storage Facilities]], this service focuses on the management of tabular data, i.e. any dataset that can be represented in a table format. | ||
| + | |||
| + | This document outlines the service design rationale, key features, and high-level architecture as well as the options for their deployment. | ||
| + | |||
| + | == Overview == | ||
| + | Tabular Data service is a system that allows to manage the entire lifecycle of tabular data. It's main characteristics are: | ||
* Exposes its operation to the end user through a gCube Portlet; | * Exposes its operation to the end user through a gCube Portlet; | ||
* Its operations can be invoked programmatically through a gCube Web Service (smart gears); | * Its operations can be invoked programmatically through a gCube Web Service (smart gears); | ||
| − | * Provides several operations for importing/exporting from/to | + | * Provides several operations for importing/exporting from/to several sources/sinks; |
* Provides data validations and transformations capabilities; | * Provides data validations and transformations capabilities; | ||
* Provides means for the management of data management processes automation. | * Provides means for the management of data management processes automation. | ||
| − | = | + | === Key Features === |
| + | The subsystem provides for: | ||
| − | + | ;comprehensive facilities for tabular data management | |
| + | :The subsystem offers a comprehensive set of data management facilities oriented to tabular data. Facilities include data import, data editing, and data filtering; | ||
| − | + | ;user-friendly interface | |
| − | + | :The subsystem offers a graphical user interface where users can visualize the data and perform operations in a very user-friendly environment. Moreover, the environment allow to actually perform a workflow by applying a template to an imported table; | |
| − | + | ||
| − | + | ||
| − | + | ;declarative approach | |
| − | + | :Instead of providing the user with means to describe the workflow as a set of transformation steps the user provides a table template as a set of properties a target table should comply with. | |
| − | + | ||
| − | + | ||
| − | + | ;flexible and open workflow definition mechanism | |
| + | :The set of workflow steps can be enriched providing wider capabilities for template descriptiveness; | ||
| + | ;re-usability orientation | ||
| + | :The subsystem is conceived to promote the reuse of its facilities in application dealing with tabular data; Moreover, it is conceived to be open so that additional functions can be easily added to serve domain specific cases; | ||
| + | |||
| + | == Design == | ||
| + | |||
| + | === Philosophy === | ||
| + | |||
| + | [[Tabular Data Service Model and Operations]] | ||
| + | |||
| + | === 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 functionality with external apps. | ||
| + | * '''Tabular Data Service''': main component of the tabular data architecture. It exposes several remote interfaces covering different areas of functionality. | ||
| + | ** '''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 functionality to the tabular data service. These functionality can be reached directly with invocations on the Operation Interface. Operation modules can work directly with data on the Data back-end 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 responsibilities 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. | ||
| + | * '''Data/Metadata back-end''': This is where raw tables data and metadata are stored and where the service keeps its management data. | ||
| − | = | + | == Deployment == |
| − | + | == Use Cases == | |
| − | + | ||
Latest revision as of 20:26, 16 December 2013
Part of the Data Access and Storage Facilities, this service focuses on the management of tabular data, i.e. any dataset that can be represented in a table format.
This document outlines the service design rationale, key features, and high-level architecture as well as the options for their deployment.
Overview
Tabular Data service is a system that allows to manage the entire lifecycle of tabular 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 several sources/sinks;
- Provides data validations and transformations capabilities;
- Provides means for the management of data management processes automation.
Key Features
The subsystem provides for:
- comprehensive facilities for tabular data management
- The subsystem offers a comprehensive set of data management facilities oriented to tabular data. Facilities include data import, data editing, and data filtering;
- user-friendly interface
- The subsystem offers a graphical user interface where users can visualize the data and perform operations in a very user-friendly environment. Moreover, the environment allow to actually perform a workflow by applying a template to an imported table;
- declarative approach
- Instead of providing the user with means to describe the workflow as a set of transformation steps the user provides a table template as a set of properties a target table should comply with.
- flexible and open workflow definition mechanism
- The set of workflow steps can be enriched providing wider capabilities for template descriptiveness;
- re-usability orientation
- The subsystem is conceived to promote the reuse of its facilities in application dealing with tabular data; Moreover, it is conceived to be open so that additional functions can be easily added to serve domain specific cases;
Design
Philosophy
Tabular Data Service Model and Operations
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 functionality with external apps.
- Tabular Data Service: main component of the tabular data architecture. It exposes several remote interfaces covering different areas of functionality.
- 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 functionality to the tabular data service. These functionality can be reached directly with invocations on the Operation Interface. Operation modules can work directly with data on the Data back-end 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 responsibilities 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.
- Data/Metadata back-end: This is where raw tables data and metadata are stored and where the service keeps its management data.
