GPMSWiki/DeveloperDocumentation/Implementation: Difference between revisions
No edit summary |
m (3 revisions) |
||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 11: | Line 11: | ||
application based on the data model described in the previous | application based on the data model described in the previous | ||
section. Since the GPMS required a persistent storage backend we | section. Since the GPMS required a persistent storage backend we | ||
decided to use the [ | decided to use the [[O2DBIWiki|O2DBI-2]] system | ||
which automatically maps the XML class descriptions onto tables that can be stored in a relational | which automatically maps the XML class descriptions onto tables that can be stored in a relational | ||
database (auto-generated object-relational mapping of Perl objects). At the same time, | database (auto-generated object-relational mapping of Perl objects). At the same time, | ||
| Line 17: | Line 17: | ||
connections to the system via a Perl or C++ client. The automatically | connections to the system via a Perl or C++ client. The automatically | ||
generated Perl server modules for all described classes have been | generated Perl server modules for all described classes have been | ||
extended with additional functionality and thus form the GPMS- | extended with additional functionality and thus form the GPMS-API. MySQL is currently | ||
used as the database backend but other relational database management | used as the database backend but other relational database management | ||
systems ( | systems (RDBMS) can be used as they are supported by the O2DBI-2 | ||
software. Figure 1 displays the current database | software. Figure 1 displays the current database | ||
schema for the GPMS database (GPMSDB) as it has been generated by O2DBI-2. | schema for the GPMS database (GPMSDB) as it has been generated by O2DBI-2. | ||
| Line 27: | Line 27: | ||
== Class descriptions == | == Class descriptions == | ||
The following sections briefly describe the relevant classes of the | The following sections briefly describe the relevant classes of the | ||
data schema (see figure 1). The five core classes | data schema (see figure 1). The five core classes Project, User, Member, Role and | ||
DataSource are complemented by several simple classes that store | DataSource are complemented by several simple classes that store | ||
additional information. | additional information. | ||
| Line 39: | Line 39: | ||
class project has been extended by several subclasses that can be | class project has been extended by several subclasses that can be | ||
used to model individual properties and features of special types of | used to model individual properties and features of special types of | ||
projects (e.g. a | projects (e.g. a textitProject::GENDB defines an additional genetic code. | ||
GenDB is an annotation system developed at the Center for | |||
Genome | Genome Research, Bielefeld University). | ||
=== [[ProjectClass]] === | === [[ProjectClass]] === | ||
| Line 67: | Line 67: | ||
=== Member === | === Member === | ||
A user has to become a member of a project in order to | A user has to become a member of a project in order to | ||
gain access to a | gain access to a Project's data. Therefore, a member object relates | ||
a user to a project. Each member is also assigned a role that | a user to a project. Each member is also assigned a role that | ||
defines the level of access for that project (see description of | defines the level of access for that project (see description of | ||
Role below). Individual configurations for a project can be | |||
stored in the | stored in the User_Project_Configs. | ||
=== Affiliation === | === Affiliation === | ||
Affiliations allow to associate users and projects with an institution | Affiliations allow to associate users and projects with an institution | ||
(e.g. | (e.g. CeBiTec). In the various web portals (e.g. MGE Portal) at the CeBiTec | ||
users may only request access to projects that belong to the same affiliation. | users may only request access to projects that belong to the same affiliation. | ||
Each user and project is assigned to an affiliation. | Each user and project is assigned to an affiliation. | ||
| Line 81: | Line 81: | ||
=== Role === | === Role === | ||
Each member of a project has a specific role that determines | Each member of a project has a specific role that determines | ||
the level of access and the | the level of access and the User's permissions for that | ||
project. For example, access can be granted on a very low level with | project. For example, access can be granted on a very low level with | ||
read-only permissions or with complete access onto all data, even with | read-only permissions or with complete access onto all data, even with | ||
| Line 104: | Line 104: | ||
=== DB_Privileges === | === DB_Privileges === | ||
DB_Privileges refer to a gpmsright and represent the DBMS-specific access | |||
privileges. They are always defined for a specific datasourcetype (see | privileges. They are always defined for a specific datasourcetype (see | ||
below). | below). | ||
| Line 113: | Line 113: | ||
project. datasources have a name, a description, a host and a | project. datasources have a name, a description, a host and a | ||
datasourcetype. The class "DataSource" has been extended by two | datasourcetype. The class "DataSource" has been extended by two | ||
special types of data-sources, a database ( | special types of data-sources, a database ( DB) and a so called | ||
Application Server (see description of | Application Server (see description of | ||
DataSource:: | DataSource::ApplicationServer below). | ||
=== Host === | === Host === | ||
| Line 126: | Line 126: | ||
contain a reference to a file that defines the database schema so that a | contain a reference to a file that defines the database schema so that a | ||
newly created database can be filled with all tables automatically | newly created database can be filled with all tables automatically | ||
after creation. A project may only have one | after creation. A project may only have one DB and one | ||
ApplicationServer of each datasourcetype so that the connection to | |||
the correct datasource can be established automatically. | the correct datasource can be established automatically. | ||
=== [[DataSource]]::[[ApplicationServer]] === | === [[DataSource]]::[[ApplicationServer]] === | ||
An | An ApplicationServer is a generic datasource that can provide data for an | ||
application. The class inherits all attributes of the datasource | application. The class inherits all attributes of the datasource | ||
class and has an additional url and a socket. Note that a project may only | class and has an additional url and a socket. Note that a project may only | ||
have one | have one ApplicationServer of each datasourcetype (see description | ||
of | of DataSource_Type). | ||
=== [[DataSource]]::DB === | === [[DataSource]]::DB === | ||
| Line 143: | Line 143: | ||
dbapi. Note that a project may only have | dbapi. Note that a project may only have | ||
one textitDataSource::DB of each individual datasourcetype (see | one textitDataSource::DB of each individual datasourcetype (see | ||
description of | description of DataSource_Type). | ||
=== DBMS_Type === | === DBMS_Type === | ||
| Line 156: | Line 156: | ||
=== Project::Meta === | === Project::Meta === | ||
Project::Meta is a generic project subclass that combines several arbitrary | |||
projects to a new project. A meta-project provides a list of | projects to a new project. A meta-project provides a list of | ||
member-projects and inherits all the attributes of project. | member-projects and inherits all the attributes of project. | ||
Author: [http://www.cebitec.uni-bielefeld.de/~lkrause Lutz Krause] | Author: [http://www.cebitec.uni-bielefeld.de/~lkrause Lutz Krause] | ||
Latest revision as of 07:14, 26 October 2011
Implementation
This chapter contains details about the implementation of the GPMS. We describe the datamodel for the relational database and explain the attributes of each class. Sample descriptions for the definition of roles and rights complement this section by illustrating the implementation of fine-grained access control.
Database schema for the GPMS
The GPMS was developed as an object-oriented application based on the data model described in the previous section. Since the GPMS required a persistent storage backend we decided to use the O2DBI-2 system which automatically maps the XML class descriptions onto tables that can be stored in a relational database (auto-generated object-relational mapping of Perl objects). At the same time, O2DBI-2 provides a client-server architecture that allows remote connections to the system via a Perl or C++ client. The automatically generated Perl server modules for all described classes have been extended with additional functionality and thus form the GPMS-API. MySQL is currently used as the database backend but other relational database management systems (RDBMS) can be used as they are supported by the O2DBI-2 software. Figure 1 displays the current database schema for the GPMS database (GPMSDB) as it has been generated by O2DBI-2.
File:GPMSWiki$$DeveloperDocumentation$$Implementation$DBSchemaGPMS.png
Class descriptions
The following sections briefly describe the relevant classes of the data schema (see figure 1). The five core classes Project, User, Member, Role and DataSource are complemented by several simple classes that store additional information.
Project
projects are the central components of the GPMSDB. They connect all relevant classes. projects have a unique name, an additional description, special configurations (e.g. global project settings), and a list of datasources. Each project belongs to a specific projectclass that is described later in this document. The general class project has been extended by several subclasses that can be used to model individual properties and features of special types of projects (e.g. a textitProject::GENDB defines an additional genetic code. GenDB is an annotation system developed at the Center for Genome Research, Bielefeld University).
ProjectClass
A projectclass arranges projects of the same type into groups. Additionally, a projectclass determines the available roles and rights for the individual projects. Hence roles and rights do not have to be defined for every project but only once for all projects of the same projectclass. This approach reduces the complexity of the system and the required work when administering projects. At the same time a concise representation of all project related data is achieved and a consistent use of roles and their corresponding permissions can be ensured. A projectclass has a name and a description. An optional default configuration file can be specified that contains standard configuration parameters. The max_instance_number can be set to define a maximal number of projects of a projectclass an application can open at the same time.
User
Basic user data is stored in user objects. Each user object has to provide a name, a login and an email address. A special flag can be set to determine whether the user is an internal or external (e.g. has access only via web frontends) user.
Member
A user has to become a member of a project in order to gain access to a Project's data. Therefore, a member object relates a user to a project. Each member is also assigned a role that defines the level of access for that project (see description of Role below). Individual configurations for a project can be stored in the User_Project_Configs.
Affiliation
Affiliations allow to associate users and projects with an institution (e.g. CeBiTec). In the various web portals (e.g. MGE Portal) at the CeBiTec users may only request access to projects that belong to the same affiliation. Each user and project is assigned to an affiliation.
Role
Each member of a project has a specific role that determines the level of access and the User's permissions for that project. For example, access can be granted on a very low level with read-only permissions or with complete access onto all data, even with the right to delete everything. Therefore, roles have a list of rights that further define such privileges. Note that roles are defined for a projectclass, not for each single project. An additional "extern" flag can be used to allow setting this role via the web frontend by external project managers. The "script" attribute can be used to store some code that is automatically executed for newly created members with this role.
Rights
rights determine the permissions of a member for a specific project. rights are associated with database privileges. If a user is added to a project as a member all the privileges determined by the rights of the corresponding role will be granted to the user. rights are defined for a projectclass, not for a single project. This approach does not only simplify the maintenance of projects but also ensures a consistent use of roles for all users that have access to projects of a specific projectclass.
DB_Privileges
DB_Privileges refer to a gpmsright and represent the DBMS-specific access privileges. They are always defined for a specific datasourcetype (see below).
DataSource
Applications often need to access and store persistent external data. These are provided as a datasource which is attached to a project. datasources have a name, a description, a host and a datasourcetype. The class "DataSource" has been extended by two special types of data-sources, a database ( DB) and a so called Application Server (see description of DataSource::ApplicationServer below).
Host
Information about the host of a typical datasource are stored in host objects. Each host has a name, a port and a description.
DataSource_Type
The datasourcetype determines the specific type of a datasource. For databases the datasourcetype can also contain a reference to a file that defines the database schema so that a newly created database can be filled with all tables automatically after creation. A project may only have one DB and one ApplicationServer of each datasourcetype so that the connection to the correct datasource can be established automatically.
DataSource::ApplicationServer
An ApplicationServer is a generic datasource that can provide data for an application. The class inherits all attributes of the datasource class and has an additional url and a socket. Note that a project may only have one ApplicationServer of each datasourcetype (see description of DataSource_Type).
DataSource::DB
This class represents all kinds of databases and extends the datasource class. In addition to all inherited attributes of the datasource class a textitDataSource::DB is described by a dbmstype and a dbapi. Note that a project may only have one textitDataSource::DB of each individual datasourcetype (see description of DataSource_Type).
DBMS_Type
The dbmstype describes the database management system that is used to store the databases (e.g. mysql). A dbmstype has a name and a version number.
DB_API_Type
The dbapi is a special class that can be used to define an api for accessing a database ( DataSource::DB). For our purposes this is in most cases an O2DBI or an OI interface.
Project::Meta
Project::Meta is a generic project subclass that combines several arbitrary projects to a new project. A meta-project provides a list of member-projects and inherits all the attributes of project.
Author: Lutz Krause