IDE architecture design

From stgo
Revision as of 10:26, 7 November 2013 by Mentaer (Talk | contribs)

Jump to: navigation, search

>> 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 data is located where highest demand is (concurrent access is not as high, manageable)
availability if the main db fails, nobody can access his data if one group db fails, then the system still works (at least locally)
scalability (adding new data from new group) 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)
easier to provide one base-dataset same base-data on several servers? danger of inconsistencies
quality assurance (geogr. data + metadata) one dedicated expert to check data quality (data description, accuracy) many experts necessary
documentation one document to create for accessing data many documents to read and maintain
availability info on data: to IDE de Chile fast to update info on data availability for IDE de Chile additional work to gather changes in data availability at different locations

(see also Distributed Database and Federated Database System)

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

  • al BD de datos (acceso directo: solo por expertos observatorio)
  • al visor de datos (login o diferente visores: publico sin login + otro con login y interfaz diferente)
  • al servicios de datos (WFS, WMS, WCS, etc)