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,…

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

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.)

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.

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.

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.

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.

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.

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.

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.

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.

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