====== Ideas de VOTA ======

===== Definiciones =====


**Servicio VOTA Central (SVC)**: Servicio web central que generará consultas
sobre una base de datos (BDs) con datos generales de los modelos que son
suministrados por cada uno de los servicios VOTA periféricos. Dentro del
esquema Cliente-Servidor de BD este servicio será el Cliente que genera
consultas sobre la BD de cada uno de los servicios VOTA periféricos.\\

//Ubicación//: LAEFF y IAA\\
//Mirrors//: IAA contendrá un mirror de SVC. El servidor de URL se configurá
 para que LAEFF sea es servidor primario y el IAA sea el secundario. Éste
 actuará en el caso que es SVC del LAEFF se caiga por cualquier motivo.\\

**Servicio VOTA Periférico (SVP)**: Servicio generador de datos y ficheros de
modelos. Dentro del esquema Cliente-Servidor de BD estos nodos actúan de
servidor de información recibiendo consultas de VOTA central.\\

//Ubicación//: En cada uno de los nodos generadores de modelos: IAA,
CAUP,...\\

===== Tecnología usada =====

Tanto el SVC como los SVPs serán desarrollados por CR usando actualmente
tecnología PHP.

===== Instalación =====

CR se ocupará de instalar el SVP en un principio en el IAA y en un futuro en cada
una de las ubicaciones remotas (como CAUP(. Para ello necesitará acceso remoto a
cada uno de los nodos. En nuestro caso al servidor DFE. (De esto se encargará JRR.)

===== Configuración =====

Dentro de cada uno de los SVP se debe especificar la ubicación de los directorios de
los ficheros de datos. Esta aplicación debe contener una herramienta para que el
propio administrador pueda cambiar la ubicación de estos ficheros de manera
transparente al SVC.

===== Consultas =====

Para aliviar el número de consultas a los SVPs se ha creado una estructura de BD en
VOTA central para “consultas ligeras”

**Consultas “ligeras”**
En VOTA central se ha creado una base de datos que contiene las características
esenciales de cada modelo suficientes para responder a las consultas más comunes
de los usuarios de VOTA. Queda por definir el contenido de esta tabla.

**Consultas “pesadas”**
En el caso de necesitar más información para generar la salida de las consultas y no
sea suficiente con la base de datos de SVC, éste remitirá la consulta, a través del
protocolo HTTP, al correspondiente SVP donde se encuentres los modelos
consultados.

===== Modelos =====

Cada SVP se compromete a rellenar de forma estandarizada, atendiendo a unidades
de medidas físicas y significado de cada una de las características, su propia BD.
Esa conversión es necesaria para la unificación de modelos de todos los SVP y será
tarea de cada uno de los centros. ¿?
CH recalca que la BD debe ser rellenada con los datos incluidos en el interior de los
ficheros y no con los nombres de estos. De esta forma conseguimos veracidad en
los datos.

===== Datasets =====

JCS propone introducir el concepto de datasets como colección de datos que se
caracterizan por basarse en la misma física.\\
La manera de implementarlo sería crear una BD específica para los dataset. Así
cuando los SVP creen modelos, no sólo deben cargar los datos de estos en la BD de
modelos sino también incluir una nueva entrada en una BD de dataset con la física
que caracteriza estos datasets ubicada en cada una de los SVPs. Además crear un
BD central con todos los dataset ubicada el SVC.\\
Cada modelo estará obligatoriamente incluido dentro de un dataset. Siendo la
unidad mínima de cada dataset un track. No puede existir un dataset vacío.
JCS propone las siguiente claves primarias para definir tracks, dataset y código\\

  * id_track (M, Z, omega, Phys)
  * id_dataset (phys_type)
  * id_code (CE,ME, F1,GR)

JCS debe explicarnos un poco más esto.

===== Sincronización de SVC con los SVPs =====

La BDs (BD de modelos y la BD de dataset) del SVC se alimenta de la información
generada por las BDs de cada una de las SVPs. Esto se realizará mediante consultas
periódicas (JRR propone 1 vez al día) del SVC sobre los SVPs preguntando si “hay
algo nuevo” tanto en modelos como en datasets.

===== Petición de ficheros =====

Una vez realizadas las consultas y si el usuario quiere los ficheros seleccionados en
las consultas se deberá pedir a través del servicio web de SVC.\\
Carlos comenta que el SVP debe contener un “Servicio VO” dando respuesta a una
petición de fichero remitida mediante una URL. Esta sería la forma de resolver las
peticiones de SVC sobre los ficheros.

===== Seguridad =====

Analizando la cuestión de las conexiones entre SVC y SVPs se decide usar un
sistema SSL (Claves asíncronas) para las conexiones HTTPS. JCS propone un
certificado de autentificación web para SVC además de un sistema de seguridad
central ubicado en este. De esta forma se ahorra que cada uno de los SVPs deban
tener su propio sistema de seguridad.\\
JRR expone que cada SVP puede tener unos criterios de seguridad distintos
(capados de SSH) y habría que analizar cada caso con cuidado.

===== Acceso a Grid =====

Se ha hablado de los certificados robot. Con el uso de ER-FLOW parece que la cosa
estaría “medio resuelta” pero hay que analizar el asunto. Ni CR ni JRR han utilizado
nunca certificados robot y, es más, JRR cree que puede dar problemas dentro de
Ibergrid, que es el sitio natural para usar nuestras aplicaciones en el Grid.

===== Prueba =====

Regular DokuWiki markup....
<wysiwyg name >>>>>33008AD8-D1B7-4739-A27F-FB64353077D1Edit me!33008AD8-D1B7-4739-A27F-FB64353077D1<<<<< />