Difference between revisions of "IDE architecture design"

From stgo
Jump to: navigation, search
(init)
 
(→‎Pro & Contra)
 
(21 intermediate revisions by one user not shown)
Line 3: Line 3:
 
== What Architectural Models exist ==
 
== What Architectural Models exist ==
  
−
=== Central Server Architecture ===
+
=== A - Central Server-Database Architecture ===
−
SDI case
+
El imagen abajo muestra una IDE simple, con 2 servidores:
 +
* Servidor web con modulo de mapas en-linea, y con catalogo de datos
 +
* Servidor con base de datos
  
−
=== Distributed Multi-Server Architecture ===
+
[[File:CEDEUS_Physical_Architecture-central.png|550px|Arquitectura Observatorio CEDEUS - tipo "central"]]
−
SDI case
+
  
−
=== Pro & Contra ===
+
=== B - Distributed Multi-DB Server Architecture ===
−
possible criteria:
+
El proximo imagen muestra una IDE complejo, con 6 servidores (con base de datos multiples):
−
* access management
+
* 3+ Servidores de grupos de investigacion  (con BD)
−
* data security
+
* 1 Servidor de Catalogo
−
* backups
+
* 1 Servidor de Mapas
−
* ...
+
* 1 Servidor con Base de Datos (Datos Centrales)
 +
(es posible de user un servidor con el modulo de mapas juntos con la base de datos)
 +
 
 +
[[File:CEDEUS_Physical_Architecture-multi-server_decentral.png|950px|Arquitectura Observatorio CEDEUS - tipo "multi-DB/decentralizado"]]
 +
 
 +
== Pro & Contra ==
 +
 
 +
Yo hice el tabla abajo con criterios que yo veo importa. Después he incorporado puntos de una lista en ingles sobre "Advantages and Disadvantages of [http://en.wikipedia.org/wiki/Distributed_database Distributed Database]" on Wikipedia.
 +
 
 +
{| class="wikitable" border="1"
 +
|-
 +
!width="250"|criteria
 +
!width="250"|single DB
 +
!width="250"|multi DBs
 +
|-
 +
! server needs (registry server, web server, base-db server)
 +
| two servers (1 web server, one db server)
 +
| at least one web server, including a registry component (e.g. GeoNetwork), and many db-servers (one for each site)
 +
|-
 +
! maintenance needs (adding data, metadata, software updates)
 +
| one admin (one update)
 +
| many local admins (many updates)
 +
|-
 +
! user access control
 +
| central access control (to resolve access requests may take time)
 +
| each group decides about data access
 +
|-
 +
! user access management
 +
| one unified user rights management for all CEDEUS members (with 4 different access groups, e.g.: admin, cedeus member, invited, public)
 +
| each DB admin needs to create its own user management system and needs to ensure access by other CEDEUS groups (However, a replication of user access rights is possible)
 +
|-
 +
! data security (un-wanted access)
 +
| one dedicated data server that can only be accessed via a gateway; direct access by very few users only (obs. team)
 +
| many databases with different user groups and different users per computer
 +
|-
 +
! data backups (copias d. seguridad)
 +
| regular backup for only one db sever
 +
| requires complex backup strategy or one backup device for each location
 +
|-
 +
! power outages
 +
| one web server and one db server in the same place are easy to "secure" with a UPS
 +
| costly to provide UPS for several server locations
 +
|-
 +
! performance (serving data => multi-access)
 +
| performance depends on server power, may be insufficient during concurrent access for multiple users
 +
| data is located where highest demand is (concurrent access is not as high = manageable)
 +
|-
 +
! availability
 +
| if the main db fails, nobody can access the data
 +
| if one group db fails, then the system is still working for others (at least locally)
 +
|-
 +
! scalability (new group with new data)
 +
| with a new group new data needs to be added, which may require lots of work hours (also w.r.t. Q/A)
 +
| easy to extend observatory by another database, if workload is done by the new group
 +
|-
 +
! geographic base-data (for maps) <br>(Well here we can also store base data on one particular assigned server)
 +
| eays unified provision of one base-dataset for all
 +
| same base-data on several servers? danger of inconsistencies (w.r.t. updates, etc.)
 +
|-
 +
! Q/A: quality assurance (geogr. data + metadata)
 +
| one dedicated GIS expert to check data quality (data description, accuracy)
 +
| many GIS experts necessary
 +
|-
 +
! documentation that describes how to access data
 +
| one document to create
 +
| many documents to read and maintain
 +
|-
 +
! IDE de Chile: availability of CEDEUS data
 +
| fast to inform SNIT about new data or updates
 +
| requires first getting info on changes for each group
 +
|-
 +
! => Summary
 +
! => fewer staff, well trained, less costly (hardware + staff)
 +
! => more staff, more costly, can save time for observatory team, easier to add a new group
 +
|}
 +
 
 +
(see also [http://en.wikipedia.org/wiki/Distributed_database Distributed Database] and [http://en.wikipedia.org/wiki/Federated_database_system Federated Database System], as well as the entry [http://en.wikipedia.org/wiki/Distributed_data_store Distributed Data Store] with examples on distributed non-relations DBs)
 +
 
 +
Btw: I am not sure if it would make sense to '''''replicate''''' data of all group DBs to a central DB. However, this could be a strategy as well.
 +
 
 +
== Tipos de Usuarios ==
 +
 
 +
=== Tipo A - Ciudadanos ===
 +
* tareas tipicos => permisos
 +
 
 +
=== Tipo B - Investigador CEDEUS ===
 +
* tareas tipicos => permisos
 +
 
 +
=== Tipo C - Persona Invitado ===
 +
* tareas tipicos => permisos
 +
* accesso al unos datos especiales
 +
 
 +
=== Tipo D - Experto de Observatorio ===
 +
* tareas tipicos => permisos
 +
 
 +
== Gestion de Acceso ==
 +
* acceso al BD de datos (acceso directo: solo por expertos observatorio)
 +
* acceso al visor de datos (login o diferente visores: publico sin login + otro con login y interfaz diferente)
 +
* acceso al servicios de datos (WFS, WMS, WCS, etc)

Latest revision as of 10:51, 7 November 2013

>> return to Cedeus IDE

What Architectural Models exist

A - Central Server-Database Architecture

El imagen abajo muestra una IDE simple, con 2 servidores:

  • Servidor web con modulo de mapas en-linea, y con catalogo de datos
  • Servidor con base de datos

Arquitectura Observatorio CEDEUS - tipo "central"

B - Distributed Multi-DB Server Architecture

El proximo imagen muestra una IDE complejo, con 6 servidores (con base de datos multiples):

  • 3+ Servidores de grupos de investigacion (con BD)
  • 1 Servidor de Catalogo
  • 1 Servidor de Mapas
  • 1 Servidor con Base de Datos (Datos Centrales)

(es posible de user un servidor con el modulo de mapas juntos con la base de datos)

Arquitectura Observatorio CEDEUS - tipo "multi-DB/decentralizado"

Pro & Contra

Yo hice el tabla abajo con criterios que yo veo importa. Después he incorporado puntos de una lista en ingles sobre "Advantages and Disadvantages of Distributed Database" on Wikipedia.

criteria single DB multi DBs
server needs (registry server, web server, base-db server) two servers (1 web server, one db server) at least one web server, including a registry component (e.g. GeoNetwork), and many db-servers (one for each site)
maintenance needs (adding data, metadata, software updates) one admin (one update) many local admins (many updates)
user access control central access control (to resolve access requests may take time) each group decides about data access
user access management one unified user rights management for all CEDEUS members (with 4 different access groups, e.g.: admin, cedeus member, invited, public) each DB admin needs to create its own user management system and needs to ensure access by other CEDEUS groups (However, a replication of user access rights is possible)
data security (un-wanted access) one dedicated data server that can only be accessed via a gateway; direct access by very few users only (obs. team) many databases with different user groups and different users per computer
data backups (copias d. seguridad) regular backup for only one db sever requires complex backup strategy or one backup device for each location
power outages one web server and one db server in the same place are easy to "secure" with a UPS costly to provide UPS for several server locations
performance (serving data => multi-access) performance depends on server power, may be insufficient during concurrent access for multiple users data is located where highest demand is (concurrent access is not as high = manageable)
availability if the main db fails, nobody can access the data if one group db fails, then the system is still working for others (at least locally)
scalability (new group with new data) with a new group new data needs to be added, which may require lots of work hours (also w.r.t. Q/A) easy to extend observatory by another database, if workload is done by the new group
geographic base-data (for maps)
(Well here we can also store base data on one particular assigned server) 		eays unified provision of one base-dataset for all same base-data on several servers? danger of inconsistencies (w.r.t. updates, etc.)
Q/A: quality assurance (geogr. data + metadata) one dedicated GIS expert to check data quality (data description, accuracy) many GIS experts necessary
documentation that describes how to access data one document to create many documents to read and maintain
IDE de Chile: availability of CEDEUS data fast to inform SNIT about new data or updates requires first getting info on changes for each group
=> Summary => fewer staff, well trained, less costly (hardware + staff) => more staff, more costly, can save time for observatory team, easier to add a new group

(see also Distributed Database and Federated Database System, as well as the entry Distributed Data Store with examples on distributed non-relations DBs)

Btw: I am not sure if it would make sense to replicate data of all group DBs to a central DB. However, this could be a strategy as well.

Tipos de Usuarios

Tipo A - Ciudadanos

  • tareas tipicos => permisos

Tipo B - Investigador CEDEUS

  • tareas tipicos => permisos

Tipo C - Persona Invitado

  • tareas tipicos => permisos
  • accesso al unos datos especiales

Tipo D - Experto de Observatorio

  • tareas tipicos => permisos

Gestion de Acceso

  • acceso al BD de datos (acceso directo: solo por expertos observatorio)
  • acceso al visor de datos (login o diferente visores: publico sin login + otro con login y interfaz diferente)
  • acceso al servicios de datos (WFS, WMS, WCS, etc)
Retrieved from "http://wiki.geosteiniger.cl/mediawiki-1.22.7/index.php?title=IDE_architecture_design&oldid=447"