GPMSWiki/DeveloperDocumentation/Implementation - Revision history

Admin: 3 revisions

2011-10-26T06:14:32Z

3 revisions

← Older revision	Revision as of 08:14, 26 October 2011
(No difference)

imported>JomunaChoudhuri at 15:11, 24 August 2005

2005-08-24T15:11:52Z

imported>LutzKrause at 11:45, 25 April 2005

2005-04-25T11:45:47Z

← Older revision		Revision as of 13:45, 25 April 2005
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-!API. MySQL is currently		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 (!RDBMS) can be used as they are supported by the O2DBI-2		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 !Project, !User, Member, !Role and		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 ~~textit!Project~~::GENDB defines an additional genetic code.		projects (e.g. a textitProject::GENDB defines an additional genetic code.
	!GenDB is an annotation system developed at the Center for		GenDB is an annotation system developed at the Center for
	Genome !Research, Bielefeld University).		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 !Project's data. Therefore, a member object relates		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		Role below). Individual configurations for a project can be
	stored in the ~~!User_!Project_!Configs~~.		stored in the User_Project_Configs.

	=== Affiliation ===		=== 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 !User's permissions for that		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		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 ( !DB) and a so called		special types of data-sources, a database ( DB) and a so called
	Application Server (see description of		Application Server (see description of
	DataSource::[[ApplicationServer]] below).		DataSource::[[ApplicationServer]] below).
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 !DB and one		after creation. A project may only have one DB and one
	[[ApplicationServer]] of each datasourcetype so that the connection to		[[ApplicationServer]] of each datasourcetype so that the connection to
	the correct datasource can be established automatically.		the correct datasource can be established automatically.
Line 135:		Line 135:
	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 [[ApplicationServer]] of each datasourcetype (see description		have one [[ApplicationServer]] of each datasourcetype (see description
	of ~~DataSource_!Type~~).		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 ~~DataSource_!Type~~).		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		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]

Unknown user at 00:00, 1 January 1970

1970-01-01T00:00:00Z

New page

__NOTOC__
= 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 [http://www.cebitec.uni-bielefeld.de/groups/brf/software/wiki/O2DBIWiki 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.

[[Image: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 textit!Project::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: [http://www.cebitec.uni-bielefeld.de/~lkrause Lutz Krause]

← Older revision		Revision as of 17:11, 24 August 2005
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 [~~http://www.cebitec.uni-bielefeld.de/groups/brf/software/wiki/~~O2DBIWiki O2DBI-2] system		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 75:		Line 75:
	=== Affiliation ===		=== Affiliation ===
	Affiliations allow to associate users and projects with an institution		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]]		(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 115:		Line 115:
	special types of data-sources, a database ( DB) and a so called		special types of data-sources, a database ( DB) and a so called
	Application Server (see description of		Application Server (see description of
	DataSource::[[ApplicationServer]] below).		DataSource::ApplicationServer below).

	=== Host ===		=== Host ===
Line 127:		Line 127:
	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 DB and one		after creation. A project may only have one DB and one
	[[ApplicationServer]] of each datasourcetype so that the connection to		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 [[ApplicationServer]] is a generic datasource that can provide data for 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 [[ApplicationServer]] of each datasourcetype (see description		have one ApplicationServer of each datasourcetype (see description
	of DataSource_Type).		of DataSource_Type).