Manual para Técnicos

Formación para técnicos

Manual del formador

2

Índice Módulo 1. Resumen de funcionalidades ................................................... 10

1. ¿Qué es? ..................................................................................... 11 2. Componentes básicos ..................................................................... 12

Módulo 2. Arquitectura........................................................................ 23

1. Introducción................................................................................ 24 2. Arquitectura física ........................................................................ 25 3. Arquitectura lógica........................................................................ 28

Módulo 3. Instalación (Componentes de la plataforma) ................................ 39

1. Capa de datos.............................................................................. 40 2. Capa de aplicación ........................................................................ 54 3. Capa de servidor web..................................................................... 91

Módulo 4. Administración....................................................................126

1. Contenidos................................................................................. 127 2. Plataforma................................................................................. 132 3. Configuración ............................................................................. 155

Módulo 5. Operación..........................................................................161

1. Arranque y parada de los aplicativos ................................................. 162 2. Ficheros de Log ........................................................................... 164 3. Backups .................................................................................... 168 4. Modificaciones frente a cambios frecuentes......................................... 171 5. Tareas planificadas ...................................................................... 172 6. Generación automática de ficheros ................................................... 174 7. Seguridad .................................................................................. 175 8. Actualización MediaWiki ................................................................ 178

Módulo 6. Integración.........................................................................181

1. Introducción............................................................................... 182 2. WebServices publicados ................................................................. 182 3. OAI-PMH.................................................................................... 188 4. Gestor de sesiones ....................................................................... 202 5. SQI .......................................................................................... 206 6. DRI .......................................................................................... 214

Referencias .....................................................................................222

3

I. Organización del taller 1. Requisitos técnicos y preparación previa de las aulas

El aula en la que se va a impartir el curso debe estar equipada con los siguientes elementos:

- Ordenador fijo o portátil; uno por cada asistente, preferiblemente. Cada

ordenador debe tener los siguientes elementos: máquina Linux Red-Hat, servidor MySQL 5.0, JDK 6, JBoss 4.0.5 GA, Apache 2, PHP 5.1, Servidor OpenLDAP 2.2.13, Squid 3 y acceso como usuario root.

- Proyector. - Conexión a Internet. - Conexión a un nodo de Agrega. - Disponer de una sala con ordenadores.

2. Recursos de apoyo que se van a utilizar

– Manual del docente formado por los materiales que se presentan a continuación. Este manual está estructurado temporalmente según la organización del taller. Para trabajar con el documento deberás tener en cuenta estos iconos:

Explicación del docente.

Proyección de diapositivas, audio y vídeo.

Actividades a desarrollar durante la explicación del contenido.

- Presentación: 78 diapositivas. - 10 actividades. - 8 animaciones.

3. Objetivos

General:

− Conocer los procedimientos para la instalación de nodos de la Plataforma. − Ser capaz de mantener operativa la Plataforma.

Específicos:

− Identificar las tecnologías de base que utiliza la Plataforma. − Reconocer la estructura, componentes, relaciones y configuración de los

mismos en los que se basa la Plataforma.

4

4. Contenidos

• Módulo 1. Resumen de funcionalidades o ¿Qué es? o Componentes básicos

• Módulo 2. Arquitectura o Introducción o Arquitectura física o Arquitectura lógica

• Módulo 3. Instalación (Componentes de la plataforma) o Capa de datos o Capa de aplicación o Capa de servidor web

• Módulo 4. Administración o Contenidos o Plataforma o Configuración

• Módulo 5. Operación o Arranque y parada de los aplicativos o Ficheros de Log o Backups o Modificaciones frente a cambios frecuentes o Tareas planificadas o Generación automática de ficheros o Seguridad o Actualización MediaWiki

• Módulo 6. Integración o Integración o WebServices publicados o OAI-PMH o Gestor de sesiones o SQI o DRI

5. Perfil del grupo

Perfil: administrador de sistemas Unix. Funciones en Agrega: mantener, actualizar el nodo de Agrega y diagnosticar los posibles problemas de servicio.

6. Conocimiento del grupo

Es fundamental a la hora de enfrentarse a una asesoría o un curso formativo valorar los conocimientos previos con los que cuenta el grupo. Esto facilitará la adecuación de los contenidos, metodología o temporalidad de cada tema, con el fin de adecuar la sesión a los intereses de los participantes. En el primer módulo es aconsejable utilizar alguna técnica de grupos para facilitar la participación posterior de los asistentes.

5

7. Agenda

La carga horaria propuesta para el taller es de 30 horas distribuidas del siguiente modo:

Lunes Martes Miércoles Jueves Viernes

9.00 -11.00

Módulo 2

Módulo 4

Módulo 5

Módulo 6

11.00-11.30 Descanso

Descanso

Descanso

Descanso

11.30-13.00

13.00-14.00

Módulo 1

Módulo 3

Módulo 4

Módulo 5

Dudas y cierre del taller Evaluación

14.00-15.30

Comida

Comida

Comida

Comida

15.30-18.00

Módulo 2

Módulo 3

Módulo 5

Módulo 6

8. Desarrollo del tema. Metodología Proponemos una metodología participativa para el desarrollo de competencias en el uso instrumental y didáctico de Agrega. Para lograrlo, se plantea la posibilidad de utilizar las prácticas como demostración y ejemplo de los contenidos previamente planteados por el formador. El taller consistirá básicamente en tres fases: • Puesta en común de los conocimientos previos de los alumnos. • Exposición oral por parte del formador (clase magistral con apoyo tecnológico) en

base al punto anterior. • Desarrollo de ejercicios prácticos realizados por los usuarios y dirigidos, en un

primer momento por el formador, con el fin de bucear en las distintas funcionalidades de la Plataforma Agrega. En esta fase el rol del formador será el de apoyo y guía ante cualquier duda que surja.

6

Secuencia de contenidos Temporalización

Presentación del grupo 10 minutos

Presentación del taller: organización, objetivos a alcanzar, contenidos, etc.) 20 minutos

Explicación del módulo 1 2 horas

Desarrollo de actividades 1 hora


Desarrollo de actividades 30 minutos




Desarrollo de actividades 1 hora y 30 minutos




Desarrollo de actividades 30 minutos

Dudas y cierre del taller 1 hora

Evaluación: comprobar el grado de adquisición de los objetivos en los participantes.

30 minutos

7

9. Desarrollo de las actividades

En función de todo lo anterior, las actividades planteadas para este taller están encaminadas a configurar los componentes que forman parte de la plataforma Agrega (servidor de datos, servidor de aplicaciones, servidor web y servidor OpenLDAP).

10. Procedimiento de evaluación

El fin de la evaluación es el de comprobar el grado de adquisición de los objetivos pretendidos en los participantes. El procedimiento de evaluación a tener en cuenta posee varios aspectos:

a. Criterios de evaluación: - Participar activamente en la sesión. - Buscar algún contenido ya creado. - Crear un contenido, catalogarlo y publicarlo. - Administrar nodos y usuarios. - Instalar la plataforma. - Comprobar la estructura, componentes, relación y configuración de los

elementos de Agrega.

b. Instrumentos: - Ordenador con conexión a Internet. - Acceso a la plataforma Agrega.

c. Metodología: participativa.

d. Temporalidad: la evaluación se llevará a cabo a través de las actividades prácticas; además, se darán 10 minutos para valorar las conclusiones de la sesión.

Proyecta las diapositivas 1 a 4 de la presentación.


Manual módulo 1 Resumen de funcionalidades

8

9

Índice Contenido del módulo 1 Resumen de funcionalidades 1. ¿Qué es? 2. Componentes básicos

2.1. Portal 2.2. Buscador 2.3. Empaquetador 2.4. Catalogadores 2.5. Administración

10

Módulo 1. Resumen de funcionalidades

Presentación del taller Comenzaremos la sesión haciendo una presentación del grupo y explicando los objetivos y contenidos del mismo.

Objetivos y contenidos

• Objetivos − Identificar la plataforma Agrega y a quién va dirigida. − Analizar los componentes básicos que componen la plataforma. − Adquirir destreza en el funcionamiento básico de la plataforma.

• Contenidos

− ¿Qué es? − Componentes básicos.

Proyecta la diapositiva 5.

11

30 min

Explicación del contenido

1. ¿Qué es? El proyecto Agrega se ha concebido para adaptarse a las necesidades específicas de cada una de las Comunidades Autónomas en el ámbito educativo, y, a la vez, aportar un marco común de relación que permita a los miembros de las distintas comunidades educativas compartir y elaborar recursos multimedia.

Por tanto, Agrega es una plataforma dirigida a toda la comunidad educativa. Es por ello que la interfaz hombre-máquina se ha diseñado y desarrollado siguiendo unas pautas y normativas de usabilidad, accesibilidad y multiidioma con el fin de garantizar una mayor facilidad de uso y universalidad de la misma.

Dicha plataforma se ha diseñado con la idea de promover la especificación de una interfaz que permita la creación de redes de repositorios digitales que se interaccionen (intercambio de información entre dos o más sistemas) con el fin de facilitar a los usuarios el acceso a los contenidos educativos almacenados en estos repositorios. El alcance incluye el desarrollo de las herramientas necesarias para la elaboración, gestión y explotación de objetos digitales educativos (ODEs) sin limitaciones estructurales para futuras ampliaciones. Un ODE es una agregación de uno o más elementos digitales, que incorporan metadatos (información complementaria que ayuda a conocer el contenido y el propósito de un ODE sin necesidad de acceder a su contenido), y que representan una unidad didáctica con significación educativa. Agrega gestiona ODEs con los siguientes estándares: • Empaquetado SCORM 2004: desarrolla contenidos de aprendizaje basados en

entornos WEB. Características: o Agrega contenido en paquetes transportables. o Realiza la ejecución y el seguimiento del contenido. o Organiza la estructura del contenido. o Define la secuenciación adaptativa de las actividades.

• Metadatos LOM-ES: organiza los datos que especifican y detallan un objeto

digital educativo. Categorías de LOM-ES: o General: información genérica del ODE en su conjunto. o Ciclo de Vida: historia y estado actual del ODE. o Meta-metadatos: describe el propio registro de los metadatos. o Técnica: requisitos y características técnicas del ODE. o Uso educativo: características educativas y pedagógicas fundamentales

del ODE. o Derechos: derechos de propiedad intelectual y condiciones de uso. o Relación: describe relaciones con otros ODEs. o Anotación: comentarios sobre la utilización pedagógica del ODE. o Clasificación: describe dónde se sitúa el ODE dentro de un sistema de

clasificación concreto.

12

Proyecta las diapositivas 6 a 10.

2 h


2. Componentes básicos A continuación se verán los principales componentes de la plataforma Agrega. 2.1. Portal

El portal consta de cuatro apartados principales:

• Portada: permite realizar diferentes búsquedas y acceder a los apartados del menú: noticias, informes, descargas…

• Búsqueda taxonómica: permite seleccionar el ámbito de búsqueda (en toda la plataforma o únicamente en CNICE) así como el tipo de búsqueda (en árbol curricular o en Tesauro ETB).

• Carpeta personal: mediante la cual se accede a la herramienta de empaquetador básico y avanzado, según el nivel.

• Administración: desde la cual es posible realizar una planificación de tareas para que se ejecuten en un tiempo determinado (por ejemplo, una carga masiva de objetos digitales educativos).

Dentro de este apartado sólo veremos la portada y la carpeta personal, ya que el resto de puntos se tratarán de forma más detallada en los apartados de Buscadores y Administración. 2.1.1. Portada (Menú lateral izquierdo) Consta de los cuatro elementos siguientes:

1. Noticias. Al acceder a este apartado nos encontramos con una pantalla donde aparecen diferentes noticias relacionadas con la plataforma, y pulsando sobre cada una de ellas aparecerá información más detallada de las mismas, pudiendo ir acompañadas de imágenes e ilustraciones.

2. Informes. Esta pantalla recoge distintos informes acerca de las consultas

realizadas de los objetos digitales educativos, es decir, informes sobre los ODE´s más valorados, más mostrados, más previsualizados, más descargados, más grandes, sobre términos de búsqueda, etc.

3. Descargas. Esta pantalla contiene todas las descargas públicas

configuradas por el administrador del nodo. Cada descarga se compone de

13

título, descripción y tamaño de la descarga. Desde esta pantalla el usuario podrá descargarse el paquete de herramientas off-line de Agrega y trabajar desde su PC sin necesidad de contar con una conexión a Internet.

4. Agrega en tu web. Incluye una serie de aplicaciones que permitirá añadir

a tu Web personal información multimedia relacionada con Agrega, como por ejemplo:

a. Agrega Slider: sirve para incluir una galería de imágenes

interactiva filtrada por palabras en una Web personal. b. Contenido dinámico: esta aplicación genera un código HTML que

el usuario puede añadir en el código fuente de su propia página Web. Este código permite visualizar una imagen de un ODE de Agrega, que cambiará cada cierto tiempo.

5. RSS o Feeds. Esta pantalla muestra un listado con los feeds disponibles en

Agrega. Un feed o canal se emplea para denominar a los documentos con formato RSS o Atom que permiten a los agregadores (herramienta similar a un programa de correo electrónico que detecta los cambios en las páginas a las que estamos suscritos) recoger información de las páginas Web sindicadas.

6. Nube de tags. Muestra las palabras clave más repetidas en los contenidos de la plataforma Agrega. El tamaño de las palabras va en función de las veces que éstas se repiten. Si nos posicionamos encima de una de las palabras, podremos ver el término y el número de veces que se repite en el índice.

2.1.2. Carpeta personal A la Carpeta Personal se accede a través de la pantalla principal. En esta carpeta se almacenarán los ODEs que el usuario tenga en fase de creación. El usuario también podrá consultar aquellos ODEs propuestos para su publicación, así como los ODEs publicados en la plataforma Agrega. La pantalla de la Carpeta personal está formada por una serie de elementos que facilitan la gestión de los ODEs y que se detallan a continuación:

1. Personales. Muestra los ODEs personales del usuario que se han creado o que han sido rechazados. Al pulsar sobre el enlace del título, se accede a una previsualización del ODE.

2. Ver historial. Se trata del historial del ODE dentro de la plataforma. Por

cada transición en el estado del ODE se crea una anotación, con la fecha, el estado del ODE (en forma de icono), comentarios y el nombre del usuario que la ha desarrollado.

3. Modificar. Con el ODE seleccionado, se accede al módulo de

empaquetador (dependiendo del perfil del usuario se accederá al avanzado o al básico) para llevar a cabo las modificaciones que se consideren oportunas.

14

4. Crear. Pulsando este botón la aplicación nos lleva al empaquetador

(dependiendo del perfil del usuario se accederá al avanzado o al básico) con el fin de crear un nuevo ODE.

5. Exportar. Permite descargar un ODE simplemente seleccionando esta

opción. Dispone de los siguientes tipos de descarga:

a. Descargas IMS. Descarga los esquemas (xsds) necesarios para la validación.

b. Descarga contenidos y metadatos. Permite descargar el contenido del ODE (sin esquemas y manifiestos) y sus metadatos en formato LOM-ES.

c. HTML. Permite descargar el contenido del ODE (sin esquemas y manifiestos), sus metadatos en formato LOM-ES y, además, un fichero index.html y los ficheros necesarios para visualizar el contenido del ODE con una apariencia similar al visualizador de la plataforma.

6. Proponer. Esta función propone la catalogación del ODE. Es obligatorio

introducir un comentario que contemple el contenido del ODE, o bien, algún aspecto que el usuario considere importante para el revisor de la catalogación o para el propio publicador. La acción quedará registrada en el historial del ODE, así como el nombre del usuario que lo ha propuesto, la fecha de publicación y el comentario registrado.

7. Eliminar. Seleccionando uno o varios ODEs y pulsando después en el botón

Eliminar, estos elementos se borrarán permanentemente de la lista de objetos personales del usuario.

8. Importar. Se trata de la pantalla de importación de los ODEs. En ella,

podremos seleccionar hasta un máximo de cinco ODEs a la vez en nuestro ordenador e importarlos. Los ODEs deben ser válidos según marca el estándar SCORM 2004.

9. Propuestos. Muestra una lista con los ODEs propuestos para catalogar por

parte del usuario. También permite acceder al historial de cada ODE propuesto. Al pulsar sobre el enlace del título, el usuario podrá previsualizar el objeto digital educativo.

10. Publicados. Muestra una lista con los ODEs creados por el usuario y que

ya han sido publicados. También se puede acceder al historial de cada ODE publicado. El enlace del título permite al usuario realizar una previsualización del mismo.

2.2. Buscador La herramienta de búsqueda permite encontrar todos los Objetos Digitales Educativos (ODEs) publicados en la plataforma. Éstos se pueden previsualizar y/o descargar. También se puede acceder al buscador desde varios puntos del portal pudiendo realizarse dos tipos de búsquedas:

• Básica: la búsqueda se realiza configurando un campo de texto.

15

• Avanzada: la búsqueda se realiza configurando un formulario de criterios detallados que permita localizar los ODEs de una forma más exhaustiva.

• Taxonómica: es la que nos permite buscar por diferentes ámbitos, seleccionando las áreas o temas que nos interesa tratar en directorios.

2.2.1. Búsqueda básica Para realizar una búsqueda básica se introduce en la caja de texto una o varias palabras clave, pudiendo utilizar wildcards y/o comillas para ampliar o acotar la búsqueda. Esta información se utiliza para buscar ajustes sobre los campos título, descripción y palabras clave del ODE. Es posible seleccionar el idioma con el cual se quiere realizar la búsqueda

2.2.2. Búsqueda avanzada Para acceder a la búsqueda avanzada, es necesario hacer clic en Avanzado, junto al buscador. Una vez que accedemos a la búsqueda avanzada nos encontramos con esta pantalla:

Los parámetros que forman parte de esta herramienta:

• Caja de texto libre. De forma similar al buscador básico, este texto de búsqueda se utiliza para buscar similitudes en los campos del ODE: título, descripción y palabras clave.

• Área curricular. En esta categoría se puede seleccionar un área curricular como criterio de búsqueda.

16

• Nivel de agregación. Se puede seleccionar la granularidad funcional para los objetos digitales que se desean buscar.

• Tipo de formato. Esta opción permite seleccionar el tipo de datos que contienen los componentes de los objetos digitales que se buscan; y, por tanto, el tipo de formato en que se puede descargar el ODE.

2.2.3. Búsqueda taxonómica Para realizar una búsqueda taxonómica es necesario estar registrado. Al seleccionar esta opción, se muestra una pantalla donde se puede seleccionar el ámbito de búsqueda (Todo Agrega o CNICE) o el tipo de búsqueda que se desea realizar (Árbol curricular o Tesauro). 2.3. Empaquetador Agrega dispone de dos modalidades de empaquetador: básico y avanzado. 2.3.1. Empaquetador básico El empaquetador básico es la versión sencilla de la herramienta de empaquetación de contenidos de Agrega, que permite generar paquetes SCORM (cursos electrónicos) a partir de los contenidos y ficheros del usuario, de modo que cumplan con los estándares soportados por la plataforma. La versión básica del empaquetador no requiere por parte del usuario ningún conocimiento sobre estándares de enseñanza electrónica. Los principales pasos para hacer uso del empaquetador son:

1. Acceder al empaquetador básico, pulsando la opción Carpeta Personal del menú superior.

2. Introducir el título. 3. Añadir carpetas a la estructura. 4. Subir contenidos y asociarlos a las carpetas de estructura. 5. Asociar contenidos a la estructura. 6. Establecer la secuencia desde la estructura.

2.3.2. Empaquetador avanzado El empaquetador avanzado es la versión más compleja de la herramienta de empaquetación de Agrega destinada a usuarios con conocimientos sobre estándares SCORM para la creación de cursos electrónicos. Esta versión avanzada incluye una gestión completa de:

• Los archivos que conforman los contenidos del ODE.

• Los recursos SCORM que agrupan los ficheros del objeto. Un recurso SCORM es una agrupación de ficheros que forma una entidad como grupo. Por ejemplo, una página HTML con sus imágenes, estilos y ficheros JavaScript.

17

• Las organizaciones del objeto y los elementos (ítems SCORM) de que se componen.

• Los sub-manifiestos agregados al objeto. A continuación, se detallarán las principales características de cada uno de los gestores que forman parte de esta versión del empaquetador:

1. Gestión de archivos. La gestión de archivos funciona exactamente igual que en el empaquetador básico, es decir, las funcionalidades de las opciones son las mismas.

2. Gestión de recursos. La vista de Recursos del empaquetador avanzado muestra un listado con los recursos disponibles en el objeto que se está creando.

3. Gestión de organizaciones. El gestor de Organizaciones permite crear, modificar o eliminar las organizaciones que conforman el ODE.

4. Gestión de sub-manifiestos. El gestor de Sub-manifiestos permite incorporar ODEs completos a nuestro objeto, copiando todos sus archivos y toda su estructura como un objeto contenido dentro de nuestro objeto.

2.4. Catalogadores La función principal del catalogador es la de introducir datos de catalogación (información) sobre el objeto digital educativo que se está creando. Dependiendo del perfil elegido habrá dos tipos de catalogador:

• Básico • Avanzado

2.4.1. Catalogador básico El catalogador básico asocia al ODE editado (mediante el empaquetador básico) la metainformación necesaria para una adecuada catalogación y posterior localización del objeto dentro de la plataforma Agrega. Para que un objeto pueda entrar dentro del flujo de publicación debe tener asociada una catalogación básica, es decir, una metainformación obligatoria que será comprobada y completada en el proceso de validación. La catalogación básica está basada en un subconjunto del estándar de metadatos LOM-ES. Los valores requeridos se solicitan mediante un formulario. Para acceder al catalogador básico hay que pinchar sobre el enlace Catalogar, situado en la barra del menú superior del empaquetador básico. El formulario del catalogador básico se compone de los siguientes campos:

• Título: campo de texto libre destinado a asignar un título al objeto que se está catalogando.

• Idioma: campo destinado para que el usuario elija el idioma predominante en el ODE. Si el ODE no tiene contenido escrito el valor

18

apropiado para este elemento es ninguno. • Descripción: campo de texto libre destinado para que el usuario realice

una descripción textual del contenido del ODE que se está catalogando. • Tipo: campo destinado para que el usuario elija el tipo específico de

recurso educativo u objeto digital. La elección se realiza eligiendo un valor de los mostrados en el combo correspondiente.

• Idioma destinatario: campo reservado para que el usuario elija el idioma utilizado por el destinatario del ODE. La elección se realiza eligiendo un valor de los mostrados en el combo correspondiente.

Otra fórmula para catalogar el ODE es a través de la inserción curricular. El árbol curricular sirve para asociar el ODE a un objetivo curricular. Está compuesto por cuatro niveles:

• Etapas

• Ciclos/Cursos

• Áreas/Materias

• Bloques de contenidos

Es posible avanzar por los diferentes niveles hasta elegir el más conveniente al que asociar el ODE. Una vez elegido el nivel habrá que pulsar en Árbol Curricular. Para publicar un ODE en la plataforma es necesario que la catalogación básica se haya realizado correctamente. 2.4.2. Catalogador avanzado El catalogador avanzado asocia al ODE editado (mediante el empaquetador avanzado) la metainformación necesaria para una adecuada catalogación y posterior localización del objeto educativo dentro de la plataforma Agrega. Para que un objeto pueda entrar dentro del flujo de publicación debe tener asociada una catalogación avanzada, es decir, disponer de una metainformación obligatoria que será comprobada y completada en el proceso de validación. Para acceder al catalogador avanzado hay que pinchar sobre el enlace Catalogar, situado en la barra del menú superior del empaquetador. La catalogación avanzada está basada en el estándar de metadatos LOM-ES. El formulario del catalogador avanzado se compone de los siguientes campos:

• General. • Ciclo de vida. • Meta-Metadatos. • Técnica. • Uso educativo. • Derechos. • Relación. • Anotación.

19

• Clasificación. 2.5. Administración Desde este apartado es posible llevar a cabo una planificación de tareas con el fin de ejecutarlas o administrarlas posteriormente en la plataforma (por ejemplo, una carga masiva de objetos digitales educativos, elaboración de noticias, etc.). Este apartado consta de tres apartados principales:

• Contenidos • Plataforma • Configuración

Estos apartados se estudiarán detalladamente en el módulo destinado específicamente a tratar las funcionalidades de la administración (Módulo 4).


Busca en la plataforma una ilustración de un cilindro hueco. Utiliza los diferentes parámetros de búsqueda que permite Agrega para acotar los resultados.

Busca en la plataforma una presentación multimedia acerca de los instrumentos de medición. A continuación, previsualízala e inserta un comentario valorando su contenido.

Crea una carpeta para crear un ODE. Recuerda que antes de nada debes dotar con un título al objeto en cuestión.

Importa un archivo y asócialo a la carpeta que has creado recientemente.

Crea un nuevo recurso desde el empaquetador avanzado. Recuerda que para acceder a la versión avanzada debes modificar tu perfil.

Crea una nueva organización para el ODE que estás elaborando. Recuerda que la organización se crea vacía, por lo que tendrás que

20

añadirle elementos a ésta.

Cumplimenta los diferentes campos del formulario con el fin de realizar una adecuada catalogación del ODE que estás creando.

21


Manual módulo 2 Arquitectura

22

Índice Contenido del módulo 2 Arquitectura 1. Introducción 2. Arquitectura física 2.1. Apache 2.2. JBoss Application Server 2.3. Base de datos: MySQL

2.4. LDAP 2.5. Servidor de ficheros: NFS 2.6. Resumen de conexiones establecidas

3. Arquitectura lógica

3.1. Nodo de objetos digitales educativos

23

Módulo 2. Arquitectura


• Objetivos − Analizar la arquitectura física y lógica de la plataforma Agrega. − Identificar los componentes más importantes de la arquitectura física. − Exponer las conexiones establecidas entre componentes físicos. − Explicar la estructura lógica de un nodo de Agrega. − Visualizar los módulos funcionales y el conjunto de servicios que ofrece

Agrega.

• Contenidos

− Introducción. − Arquitectura física. − Arquitectura lógica.


24

30 min


1. Introducción En el bloque actual describiremos la arquitectura física y lógica de un nodo de la plataforma. Un nodo operativo esta formado por un conjunto de servicios (que pueden ejecutarse en una o varias máquinas físicas o virtualizadas diferentes) formando así una aplicación web completa, el portal Agrega. Un nodo responde a la arquitectura de 3 capas o niveles empleada típicamente en los portales web:

Capa servidor Web Apache PHP (MediaWiki) Squid (caché opcional)

Capa de aplicación JBoss Application Server JDK 1.6 Galería de Imágenes

Capa de datos NFS Base de datos (MySQL) LDAP

La capa del servidor web se encuentra formada por la aplicación de Apache, sobre la cual se instalará el módulo de PHP 5.X y la ayuda que se encuentra elaborada sobre la aplicación MediaWiki 1.12.0. En la capa de aplicación encontramos la JDK 1.6.0, el servidor de aplicaciones JBoss y por último la galería de imágenes. En secciones posteriores entraremos en detalle sobre los mismos. Por último, la capa de datos debe ofrecer un directorio compartido visible desde el Apache y el JBoss (típicamente vía NFS aunque valdrían otras soluciones), una base de datos (en nuestro caso MySQL) sobre la cual se crearán las tablas y usuarios tanto de la plataforma como de la ayuda MediaWiki, y por último debe existir un servicio de LDAP corriendo para la autenticación de los usuarios. En la siguiente sección describiremos una arquitectura física modelo que puede no coincidir con la instalación real. Desde el punto de vista arquitectónico, se podrían instalar todas las capas en una misma máquina física, pero se desaconseja por razones tanto de rendimiento como de seguridad.

25

1 h 30 min


2. Arquitectura física La arquitectura física (modelo de referencia) que se plantea es la que se muestra en la siguiente figura:

En el diagrama1 mostrado se ha optado por independizar cada servicio en una máquina diferente, no obstante, no es estrictamente necesario que en producción se dispongan de tantas máquinas físicas como servicios. Como regla general es conveniente dejar el servidor web Apache en la zona desmilitarizada (DMZ) por razones de seguridad, y en caso necesario el servidor que alberga la base de datos podría también albergar el LDAP. Debido a la carga de CPU, número de ficheros abiertos y número de conexiones se recomienda que el servidor JBoss se ejecute sobre una máquina física sin compartir recursos con otros servicios. 2.1. Apache Por razones de seguridad se propone que el servidor web Apache se instale en la zona desmilitarizada (DMZ). El servidor web atenderá peticiones en el puerto 80 (HTTP) y 443 (HTTPS). Accederá por medio de cortafuegos a la red interna al

1 Para simplificar la figura no se han representado las redes de gestión que suelen existir para la propia gestión de las máquinas, sin embargo, si se han diferenciado las redes de aplicación de las redes de almacenamiento.

26

puerto 8009 (Conector AJP) del servidor de aplicaciones JBoss. Hay que tener en cuenta que la ayuda (MediaWiki) es un módulo PHP que se ejecutará sobre Apache y que realizará conexiones a la base de datos MySQL. Es posible crear una base de datos aislada para tal propósito, incluso instalarla en la propia máquina de Apache si no queremos abrir conexiones hacia nuestra base de datos interna. La mejor opción consiste en limitar el acceso de los usuarios a la base de datos por dirección IP. A la hora de instalar Apache debemos decidir si deseamos que sirva directamente los contenidos estáticos, para lo que será necesario que éstos se instalen en una partición compartida accesible tanto desde el JBoss como desde Apache, o si, por el contrario, por cada petición queremos que se redirija al JBoss (aunque se traten de contenidos estáticos tales como CSS, JS, GIF…). En función de una u otra opción será necesario o no configurar el espacio de disco compartido por NFS. 2.2. JBoss Application Server La aplicación del portal de Agrega se desplegará sobre el servidor de aplicaciones JBoss que se ejecutará con la versión JDK 1.6. Desde JBoss se necesitará tener acceso tanto al servidor LDAP (para autenticar a los usuarios) como a la base de datos MySQL (para autorizar, cargar contenidos, localizar, noticias, faq…). Es obligatorio que el servidor del JBoss disponga de un volumen montado con gran capacidad de almacenamiento (ya sea desde un servidor con un array de discos exportados por NFS o bien directamente discos locales al servidor). Si se decide que Apache sirva directamente los contenidos estáticos, es necesario que JBoss haga uso del directorio compartido exportado por NFS para que dichos contenidos puedan ser servidos directamente desde el servidor web. 2.3. Base de datos: MySQL La plataforma de Agrega necesita hacer uso de una base de datos, en concreto, de MySQL (es posible ejecutar el portal con otras bases de datos). En la base de datos del portal se albergarán las tablas relacionadas con el uso y funcionamiento de Agrega (auditoria, búsquedas realizadas, localizador de ficheros en disco, noticias, categorías, roles de usuarios…) y en la base de datos de la Mediawiki se almacenarán todos los textos de la ayuda. Hay que tener en cuenta que, al encontrarse la ayuda basada en el software libre de MediaWiki, se ejecuta directamente sobre Apache (es una aplicación PHP). Con el fin de asegurar al máximo la plataforma se sugiere que se configuren los usuarios de conexión desde la MediaWiki especificando las IPs permitidas y dando acceso únicamente a la base de datos de la MediaWiki. 2.4. LDAP El portal de Agrega se autentica contra el LDAP haciendo el uso de la operación “bind”. Si la comunidad autónoma ya dispone de un LDAP, durante la instalación bastaría con crear la nueva estructura del portal y los usuarios iniciales, configurando posteriormente el acceso al mismo desde la configuración del portal. Si no se tuviera ningún LDAP, se recomienda la instalación de OpenLDAP v2.

27

2.5. Servidor de ficheros: NFS En el caso de desear servir los ficheros estáticos directamente desde Apache, es necesario que algún servicio exporte vía NFS un directorio compartido montado desde Apache y JBoss. En ese directorio compartido encontraremos no sólo los ficheros estáticos de la apariencia del portal (CSS, JS, GIF…) sino que también encontraremos todos los recursos de los ODEs cargados en la misma (por ejemplo un recurso puede ser una secuencia animada flash, un fichero OGG, un video AVI…). 2.6. Resumen de conexiones establecidas Las conexiones que se deben tener en cuenta en las conectividades (rutas) y reglas de los firewalls son las siguientes:

Host Origen Puerto Origen Host Destino Puerto Destino * (ANY) * (ANY) Apache 80 * (ANY) * (ANY) Apache 443

Apache * (ANY) JBoss 8009 Apache * (ANY) MySQL 3306

* (ANY) * (ANY) JBoss 8080

JBoss * (ANY) LDAP 389 JBoss * (ANY) MySQL 3306

Con el fin de ilustrar las conexiones establecidas, mostramos la siguiente figura:


28

2 h 30 min


3. Arquitectura lógica La plataforma se desarrolla con la tecnología Java (J2EE v1.4) y tiene una Arquitectura Orientada a Servicios (SOA) donde el papel del proveedor de servicios lo interpretará el Nodo de Objetos Educativos Digitales y el papel consumidor lo interpretarán las Aplicaciones Clientes, según el siguiente esquema:

La Arquitectura Orientada a Servicios (SOA), define los servicios de los cuales estará compuesto el sistema y sus interacciones. Desde el punto de vista del consumidor, los servicios son conceptualmente similares a los componentes tradicionales, salvo que los servicios encapsulan sus propios datos y no forman parte, estrictamente hablando, de la aplicación sino que son utilizados por ésta. Otra de las facetas interesantes de la arquitectura SOA es que permite realizar aplicaciones modulares que exponen la lógica de negocio que se decida para ser consumida por terceros. Destacamos el componente de Interfaz de Interoperabilidad que se basa en el estándar de interoperabilidad de Repositorios de IMS (IMS-DRI), que proporciona la funcionalidad básica para explotar los objetos digitales presentes en el repositorio (Buscar, presentar y almacenar). La tecnología que los implementa es la de Web Services que proporciona el sustento de servicios de una arquitectura orientada a servicios.

29

Las búsquedas de contenidos se realizarán con un sistema federal basado en la especificación Simple Query Interface (SQI). Al estar SQI promovido por la Comisión Europea, su adopción facilitará la integración de la Plataforma en las redes europeas de repositorios educativos. En la definición de los servicios no incluidos en IMS DRI que deban incorporarse a la Interfaz de Interoperabilidad se tomará como fuente de inspiración las Open Service Interface Definitions (OSIDs) elaboradas por el MIT en Open Knowledge Initiative (OKI). El Nodo incorpora un repositorio que almacena los contenidos empaquetados conforme al estándar SCORM 2004, aunque proporcionará paquetes en los formatos SCORM 2004, SCORM 1.2 e IMS-CP. La información de catalogación se almacena conforme al estándar LOM v.1.0 en español (LOMES). Como parte de las aplicaciones cliente, se desarrolla un portal, denominado Portal M.E.C., que sirve de escaparate al proyecto y que permite a sus visitantes el acceso a los contenidos públicos albergados en cualquiera de los nodos de la Plataforma. Además, se implementa una estructura de portal en cada Comunidad Autónoma, denominada Portal CC.AA., que permite crear instancias del mismo adaptándolas a las necesidades específicas. 3.1. Nodo de objetos digitales educativos En la siguiente figura se representa la estructura del Nodo:

30

3.1.1. Sistema de almacenamiento La naturaleza de la información manejada por la Plataforma es muy heterogénea y por ello se propone utilizar al menos tres sistemas:

• Directorio LDAP: en él se almacenará la información utilizada en los módulos de autenticación.

• Sistema de ficheros en disco: se utilizará para aquella información que, de forma natural, se suele almacenar en archivos, por ejemplo: contenidos, metainformación LOM, trazas del sistema de auditoria, logs, etc.

• Base de datos: la mayor parte de la información manejada por la Plataforma será almacenada en el sistema de ficheros. Parcialmente existirán datos que por su naturaleza (carácter relacional), serán almacenados en una base de datos relacional.

3.1.2. Capa de acceso a datos Este elemento de la arquitectura tiene como objetivo proporcionar a los módulos funcionales un elevado nivel de abstracción sobre los detalles referentes a cómo los objetos persisten en el sistema de almacenamiento. De esta forma la implementación de los módulos funcionales se centrará en la lógica de negocio. 3.1.3. Módulos funcionales e Interfaz de Interoperabilidad Cada módulo funcional encapsula e implementa un conjunto de servicios que serán ofertados al resto de elementos que componen el sistema, utilizando para ello una o varias interfaces bien definidas. Entre los servicios que se ofrecen, destacamos:

Componente Descripción

DRI

Componente encargado de la orquestación de los diferentes servicios lógicos que componen el nodo de forma que permita ofrecer al exterior una capa de webservices, denominada Interfaz de interoperabilidad con las funcionalidades de Presentar / Almacenar, Buscar / Mostrar y Solicitar / Entregar. Este componente será el encargado de recibir las peticiones del exterior y transformarlas en el lenguaje entendible por cada uno de los servicios lógicos que utilice, por ejemplo de VSQI a LQS.

• Expone: Este componente ofrece un único interfaz hacia al exterior con, al menos, los métodos anteriormente nombrados. Este interfaz será consumido por los el resto de nodos que implementen el protocolo DRI.

• Consume / Utiliza: El componente para ofrecer su funcionalidad se apoyará en los servicios de la capa de organización ofrecidos por los componentes

o Publicar, con el objetivo de poder realizar la funcionalidad de Presentar / Almacenar.

o Buscar, con el objetivo de ofrecer el Buscar / Mostrar.

31

o Entregar, con el fin de ofrecer la funcionalidad necesaria y definida por DRI para el Solicitar / Entregar.

OAI-PMH

Componente encargado de la coreografía de los diferentes servicios lógicos que compondrán el nodo de forma que se permita a buscadores tipo Google, tener información acerca de los contenidos digitales almacenados en el repositorio que expone el nodo cumpliendo el protocolo. Para ello los metadatos que se van a devolver por parte de este componente serán del tipo Dublín Core. Al igual que el componente anterior la exposición del servicio hacia el exterior será a través de webservices.

• Expone: Este componente ofrece un interfaz único al exterior que será consumido únicamente por los sistemas que comprendan el protocolo PMH.

• Consume / Utiliza: Este componente consume servicios ofrecidos por los componentes siguientes:

o Buscar: Con el objetivo de obtener todos los objetos digitales existentes dentro del repositorio que hayan cambiado desde la última búsqueda que se realizó.

o Validador / Transformador: Para transformar los metadatos LOM-ES al formato soportado por el protocolo PMH de Dublín Core.

Buscar

Componente encargado de ofrecer servicios de búsqueda y transformar las diferentes búsquedas en el lenguaje entendible por el servicio de Buscador / Indexador.

• Expone: Este componente expone dos interfaces uno encargado de las búsquedas locales, utilizado por los componentes DRI y OAI-PMH, con el objetivo de devolver objetos únicamente existentes en el nodo otro de búsquedas federadas utilizado por las herramientas propias del sistema así como para las búsquedas internas. No obstante si desde la herramienta se decide que no se hagan búsquedas federadas este componente será capaz de utilizar la búsqueda local internamente.


o Indexador / Buscador: Con el objetivo de realizar las búsquedas sobre el motor de búsqueda y los índices en función de la petición que se reciba.

Empaquetación

Componente encargado de ofrecer servicios principalmente al Empaquetador de forma que gestiona la funcionalidad de empaquetado de un usuario en su propio lugar de trabajo dentro del repositorio. Su ámbito llega hasta que el objeto digital es propuesto para publicación y éste pasa al entorno del componente de Publicación.

• Expone: Este componente expone un único interfaz encargado de gestionar las diferentes acciones que el usuario realice sobre el interfaz de usuario. Así será el encargado de guardar y modificar entre otros.


o Localizador: Con el objetivo de obtener en qué parte

32

del repositorio se va a almacenar el contenido. o Validador / Transformador: Para poder realizar las

validaciones correspondientes sobre el estándar de empaquetado SCORM2004.

o Catalogación: Se utilizará, por ejemplo, para el empaquetador básico, ya que el sistema deberá ir catalogando ciertos campos del contenido de forma interna.

o Publicación: Se utilizará, para indicar que un objeto ha comenzado su ciclo de vida y por tanto se encuentra en estado de CREACIÓN.

Publicación

Componente encargado de ofrecer servicios al Gestor de Flujo de forma que gestiona el flujo de publicación seguido por un contenido digital. También proporciona al componente DRI el servicio y la funcionalidad que se expone en el interfaz de interoperabilidad de Presentar / Almacenar. Será el encargado de generar los identificadores MEC a asignar a los ODEs que se publiquen.

• Expone: Este componente expone dos interfaces uno encargado de gestionar el flujo de publicación de los contenidos digitales existentes en el repositorio y de dar soporte a las solicitudes desde la herramienta de publicación y el segundo interfaz se encarga de dar soporte a las peticiones remotas de Presentar / Almacenar.


o Localizador: Con el objetivo de obtener en qué parte del repositorio se va a almacenar el contenido.

o Indexador / Buscador: Ya que si un objeto es publicado en el repositorio éste debe ser localizable mediante una búsqueda por ello es necesario que el contenido se indexe. Además si el contenido es despublicado o eliminado se debe quitar del índice.

o Validador / Transformador: Utilizado para validar los objetos que una vez credos se va a proponer y/o a publicar. Solo un objeto correcto y válido podrá ser propuesto y / o publicado.

Entregar

Componente encargado de ofrecer los servicios para poder consumir los objetos digitales existentes en el repositorio. Estos objetos digitales se pueden previsualizar si la llamada proviene del previsualizador, ya sea con secuencia guiada no condicionada o sin secuencia. Este último caso se dará tanto si el contenido no soporta secuencia como si es solicitado a través del componente DRI por cuestión de rendimiento. Los objetos digitales también se podrán devolver en forma de PIF en diferentes formatos SCORM 2004 (con o sin submanifiesto), SCORM 1.2 e IMS CP. Además, este componente sirve de puente de información entre los distintos módulos de presentación y el previsualizador. Así será utilizado por parte del empaquetador, para dejar el ODE en fase de creación para previsualizarlo. Este módulo además permitirá las descargas de los ODEs disponibles en la plataforma. Se llamará, por tanto desde el buscador.

• Expone: Este componente expone dos interfaces, uno

33

encargado de gestionar y entregar los paquetes a peticiones externas de previsualización o a peticiones de paquetes PIF en cualquiera de los formatos soportados. Y el otro interfaz encargado de dar soporte a las peticiones internas y que por tanto podrá soportar las secuencias guiadas no condicionadas.


o Localizador: Con el objetivo de obtener en qué parte del repositorio se va a encuentra almacenado el contenido.

o Validador / Transformador: Utilizado para transformar los contenidos digitales empaquetados en el repositorio, de SCORM 2004 a cualquiera de los otros formatos soportados.

Catalogación

Componente encargado de ofrecer los servicios para poder catalogar, según el estándar LOM-ES, los distintos contenidos generados y / o almacenados en el repositorio.

• Expone: Este componente expone un único interfaz utilizado por la herramienta de Catalogación para dar respuesta a las peticiones del usuario.


o Fuentes Taxonómicas: Lo utiliza para enlazar las diferentes fuentes taxonómicas y vocabularios controlados con el Catalogador así como para obtener la estructura educativa y curricular almacenada por este componente.

o Validador / Transformador: Este componente es utilizado con el fin de poder validar contra el esquema del LOM-ES que la catalogación realizada es la correcta.

Contenidos Portales

Componente encargado de ofrecer los servicios para poder realizar operaciones sobre los contenidos que se publicarán en el portal, entendiendo como contenidos, las noticias, los feeds y las descargas. Este componente, por un lado dará soporte al portal de administración por el cual se podrán introducir y dar de alta nuevos elementos de los anteriormente enumerados y por otro lado al portal público de la aplicación en el que los usuarios podrán visualizar las noticias y los feeds o descargarse los recursos puestos a su disposición.

• Expone: Este componente expone un único interfaz utilizado, como se acaba de comentar, por el Portal de Administración y por otro lado por el Portal público.

• Consume / Utiliza: Este componente es autocontenido y toda la información que necesita la posee en su interior por lo que no consume ningún servicio.

Modificador

Componente que implementa los servicios de la herramienta de modificación introducida en el cambio C14. Permite configurar tareas para la modificación en bloque de múltiples ODEs y se encarga de ejecutar dichas tareas y generar informe de resultados.

• Expone: Este componente expone un único interfaz utilizado

34

por la capa de presentación de la Herramienta de modificación. El interfaz expone métodos para la configuración / modificación eliminación de tareas, ejecución y visualización de resultados.


o Validador. Se utiliza para validar los ODEs que han sido modificados por una tarea.

o Publicador. En el caso de que un ODE modificado estuviera publicado en el repositorio del nodo, el publicador se encarga de su reindexación.

o Fuentes Taxonómicas: Ofrece la información necesaria para configurar modificaciones sobre catalogaciones LOM-ES (vocabularios controlados y rutas taxonómicas).

o Planificador: Permite programar la ejecución diferida de las tareas configuradas.

Valoración

Componente que se encargará de la gestión de la valoración que se dé por parte de los usuarios a los contenidos. La valoración es un campo que influye en la indexación por ello se encargará también de reindexar los objetos dentro del índice.

• Expone: Este componente expone un único interfaz utilizado por el sistema de reputación que permitirá dar de alta un comentario y una valoración asociada a un ODE así como mostrar los comentarios previamente creados, de forma que el componente de Informes pueda realizar consultas sobre este campo.


o Indexador / Buscador: Se utiliza para reindexar un documento sobre el que se ha modificado su valoración.

Indexador y Buscador

Componente que conforma un recubrimiento lógico del interfaz propuesto por la librería de indexación y búsqueda de Apache Lucene. Se encarga por tanto de la indexación de todos los ODE, así como de proporcionar la búsqueda de los mismos. Esta búsqueda se limita a la búsqueda local dentro del nodo, ya que la búsqueda federada es controlada desde el elemento federador que es el componente Buscar.

• Expone: Este componente expone dos interfaces uno para que se realicen búsquedas sobre los índices y otro, para, precisamente, realizar los índices.

• Consume / Utiliza: Este componente es auto contenido y conoce los objetos a indexar y el lenguaje de búsqueda por tanto, no necesita la utilización de ningún otro componente.

Fuentes Taxonómicas

Componente que engloba la gestión y explotación de las fuentes taxonómicas, los tesauros, árboles curriculares y los vocabularios controlados. Éstos se importan conforme a un esquema previamente definido en formato IMS VDEX. Se utilizarán diferentes formatos dependiendo de la naturaleza de la fuente taxonómica (organización jerárquica o tesauros). Además, permite realizar las traducciones de los elementos

35

existentes en dichos vocabularios controlados. Se usa, por tanto por el buscador avanzado, para rellenar sus campos de búsqueda así como para mostrar el árbol curricular.

• Expone: Este componente expone dos interfaces, una para el tratamiento de fuentes taxonómicas y otro para el de vocabularios controlados. Ambos son utilizados por el componente Catalogación con el objetivo de, por ejemplo, asignar un ODE a un determinado objetivo curricular.

• Consume / Utiliza: Este componente es auto contenido y conoce cómo gestionar las diferentes taxonomías, tesauros y vocabularios controlados.

Además de los servicios enumerados que son consumidos o utilizados por los componentes anteriormente descritos, cabe destacar que todos ellos utilizarán el interfaz propuesto por el componente de Seguridad para comprobar si quien accede está o no autorizado a realizar una u otra determinada operación, así como el interfaz ofrecido por el componente de Auditoria para dejar rastro de la operación realizada. El despliegue de los componentes citados se realiza sobre el servidor de aplicaciones mediante ficheros WAR. Gracias a la arquitectura SOA empleada algunos servicios (ofrecidos por determinados WARs) podrían ser desplegados en diferentes servidores de aplicaciones JBoss y todos los servicios que se necesitaran consumir o proveer se accederían a través de los WebServices publicados. Desde el punto de vista del servidor de aplicaciones JBoss, podemos ver el portal Agrega mediante la clásica arquitectura de 3 niveles o capas:

Los usuarios se conectan mediante el navegador a los módulos web (WARs desplegados) que exponen la parte visual del portal. Cada módulo de la capa de presentación puede consumir uno o más servicios de los publicados en la capa de negocio, quienes a su vez, hacen uso de la capa de datos correspondiente. Dentro

36

de la capa de negocio encontramos módulos orquestadores que consumen uno o más subservicios para acometer su objetivo.


¿Qué pasos debes dar para monitorizar las conexiones existentes en el nodo?

¿Cómo puedes probar el rendimiento de las redes?

37


Manual módulo 3 Instalación

(Componentes de la plataforma)

38

Índice Contenido del módulo 3 Instalación (Componentes de la plataforma) 1. Capa de datos 1.1. Sistema de ficheros

1.2. Bases de datos 1.3. Autenticación LDAP

2. Capa de aplicación 2.1. JDK 1.6 2.2. Servidor de aplicaciones JBossAS 2.3. Galería de imágenes 3. Capa de servidor web

3.1. Apache 2 3.2. Ayuda MediaWiki 3.3. Proxy cache: Squid

39

Módulo 3. Instalación (Componentes de la plataforma)


• Objetivos − Analizar los componentes necesarios de Agrega. − Describir la funcionalidad requerida para Agrega de cada componente. − Identificar los ficheros de configuración de cada uno de los

componentes, así como los scripts empleados durante la instalación. − Comprobar el correcto funcionamiento de los componentes.

• Contenidos

− Capa de datos. − Capa de aplicación. − Capa de servidor web.


40

1 h


1. Capa de datos En el presente bloque analizaremos todos los componentes que forman la plataforma, describiremos la funcionalidad requerida, los ficheros de configuración destacables, los scripts empleados durante la instalación y por último especificaremos como comprobar el correcto funcionamiento de los mismos. El portal Agrega, en función de la naturaleza de los datos a consultar o almacenar, hace uso de 3 recursos diferentes a la hora de almacenar la información:

• Sistema de ficheros • Base de datos • Directorio LDAP

1.1. Sistema de ficheros En función del número de recursos educativos a almacenar por parte del portal será necesario disponer de un determinado espacio en disco. Los discos pueden ser montados directamente en la máquina a través de cualquier array o librería de discos, conexiones SCSI directas, etc. Los contenidos que se albergarán en el sistema de ficheros son:

• Repositorio de ODEs: cada ODE estará formado por una estructura de meta información, ficheros XML… y los recursos propios del objeto digital educativo, como pueden ser imágenes, animaciones flash, videos, sonidos mp3, ogg…

• Esquemas XML. • Plantillas. • Informes: reportes generados por la aplicación BIRT. • Miniaturas (previsualizaciones) de los objetos capturadas por la galería de

imágenes. • Descargas disponibles desde la plataforma (herramienta off-line…) • Logs.

Normalmente, en los CPDs se suele disponer de servidores dedicados que exportan vía NFS2 los volúmenes lógicos definidos a partir de las librerías de discos que tienen conectados. En el caso de la plataforma Agrega, asumiremos que existe un servidor con discos conectados (no es tema de discusión de este manual cómo conectar los discos al servidor) que exportará vía NFS el directorio compartido, directorio que montará tanto el servidor del JBoss como el servidor web Apache.

2 Si no existiera el servidor dedicado NFS con los discos compartidos, el espacio estuviera disponible directamente desde la máquina del JBoss, y se deseara que Apache puediera acceder también al espacio para servir directamente los contenidos, se tendría que aplicar de igual manera la política de exportación/importación teniendo en cuenta que el exportador en lugar de ser el servidor NFS sería el servidor JBoss y que el importador sería únicamente el servidor Apache.

41

En la figura anterior se representa cómo el servidor de archivos NFS exporta un directorio tanto al servidor JBoss como al servidor Apache. 1.1.1. Servidor NFS El servidor de archivos NFS será un servidor con uno o varios discos de gran capacidad conectados (usando LVM o no) con la capacidad de exportarlos vía NFS. Aconsejamos que el sistema de ficheros de la unidad exportada sea ReiserFS o XFS (en un anexo posterior se explica cómo conseguir soporte XFS en un sistema operativo GNU/Linux) debido a las menores restricciones que se imponen en cuanto a máximo tamaño de ficheros, máximo número de subdirectorios por directorio, etc. Los archivos de configuración a tener en cuenta son:

1. /etc/exports 2. /etc/hosts.allow 3. /etc/hosts.deny

El contenido del fichero /etc/exports es: <directorio> <ip1>(opciones1) <ip2>(opciones2) #Ejemplo /export 10.0.0.0/8(rw,no_root_squash) En donde:

• <directorio> es el directorio que queremos compartir • <ip1> <ip2> son las direcciones IPs, o direcciones de red (A.B.C.D/mascara) • Opciones: especificamos el acceso que la máquina a la que exportamos

tendrá sobre el directorio. Destacamos: o ro: montaríamos el directorio de solo lectura. o rw: el cliente puede leer y escribir. o no_root_squash: por defecto, si en la máquina cliente el usuario

root crea un fichero, en el servidor NFS se trata como si lo creara el usuario nobody. Si seleccionamos la opción no_root_squash, si en la máquina cliente root crea un fichero, en la máquina servidor será también creado con el usuario root.

42

o sync: el comando de exportfs usa un comportamiento asíncrono, indicando al cliente que la escritura del fichero se ha completado cuando NFS ha terminado de gestionar la escritura en el filesystem local. Este comportamiento puede causar corrupción de datos si el servidor reinicia. El flan sync previene este fallo.

Los ficheros /etc/hosts.allow y /etc/hosts.deny especifican direcciones IPs (también valen rangos con máscara) que pueden utilizar los servicios especificados en nuestro servidor NFS. Cuando un cliente se conecta, se realizan las siguientes comprobaciones en el siguiente orden:

• Primero se comprueba si el cliente que conecta se encuentra en el fichero hosts.allow. Si es así se le permite el acceso.

• Si no se encontraba en el fichero anterior, se comprueba si el cliente está especificado en el fichero hosts.deny. En caso afirmativo, se le deniega el acceso.

• Si el cliente no se encontraba ni en el fichero hosts.allow ni en el fichero hosts.deny, se le permite el acceso.

En nuestro caso, con el fin de protegernos frente a escrituras no autorizadas en el disco compartido (desde otras máquinas que no sean ni el servidor JBoss ni el servidor Apache), configuraríamos el fichero /etc/hosts.allow de la siguiente manera: portmap: <ip_jboss>, <ip_apache> lockd: <ip_jboss>, <ip_apache> rquotad: <ip_jboss>, <ip_apache> mountd: <ip_jboss>, <ip_apache> statd: <ip_jboss>, <ip_apache> Y el fichero /etc/hosts.deny denegando el acceso a todos los demás: portmap:ALL lockd:ALL mountd:ALL rquotad:ALL statd:ALL Una vez configurados los ficheros anteriores, deberemos tener un kernel 2.4.X o superior con soporte NFS-server, los binarios del nfs-server (en cada distribución el paquete se llamará de una manera u otra) y el proceso de arranque generalmente será: /etc/init.d/nfs start Los procesos que se deben arrancar con el comando anterior son el portmapper y los 5 demonios: rpc.portmap, rpc.mountd, rpc.nfsd, rpc.statd, rpc.lockd y rpc.rquotad. Para comprobar que se encuentra correctamente arrancado ejecutamos el comando: rpcinfo -p localhost y deberíamos obtener una salida como la siguiente:

43

program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 629 status 100024 1 tcp 632 status 100011 1 udp 969 rquotad 100011 2 udp 969 rquotad 100011 1 tcp 972 rquotad 100011 2 tcp 972 rquotad 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 4 udp 2049 nfs 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100021 1 udp 32768 nlockmgr 100021 3 udp 32768 nlockmgr 100021 4 udp 32768 nlockmgr 100021 1 tcp 32768 nlockmgr 100021 3 tcp 32768 nlockmgr 100021 4 tcp 32768 nlockmgr 100005 1 udp 994 mountd 100005 1 tcp 997 mountd 100005 2 udp 994 mountd 100005 2 tcp 997 mountd 100005 3 udp 994 mountd 100005 3 tcp 997 mountd 1.1.2. Cliente NFS Como prerrequisito el kernel del sistema operativo del cliente NFS debe tener soporte para el sistema de ficheros NFS. En caso de no tenerlo es necesario actualizar el kernel a uno que si lo tenga. Para configurar que se monten las unidades de red NFS automáticamente durante el arranque es necesario configurar el fichero /etc/fstab agregando la siguiente línea: # device mountpoint fs-type options dump fsckorder 10.175.0.100:/export /export nfs defaults 0 0

• En device especificamos la dirección ip seguida del directorio compartido del servidor NFS a montar.

• En mountpoint especificamos el punto de anclaje local, es decir, en que directorio del cliente se va a montar el directorio de la unidad de red remota.

• El fs-type ha de ser nfs. • En opciones especificamos que usaremos las opciones por defecto.

La próxima vez que reiniciemos la máquina se montará automáticamente el directorio remoto. Para comprobar que se realizará correctamente podemos ejecutar el comando: “mount /export” para que se efectúe el montado en el momento.

44

1.1.3. Anexo: Soporte XFS XFS es un sistema de archivos de 64 bits con journaling de alto rendimiento creado por SGI. Se incorporó en la versión 2.4.25 del kernel de Linux (por considerarse suficientemente estable). Además, es posible aumentar la capacidad de sistemas de ficheros XFS: xfsgrowfs es ideal para particiones LVM. Para poder emplear XFS necesitamos satisfacer 2 requerimientos:

• Kernel con soporte para el sistema de ficheros XFS • Paquete con utilidades para gestionar la partición XFS

Para comprobar si nuestro kernel tiene soporte XFS compilado como módulo podemos ejecutar el siguiente comando: ls /lib/modules/$(uname -r)/kernel/fs/xfs* Si el comando anterior muestra en la salida xfs.ko significa que nuestro kernel tiene soporte. Podría darse el caso en el cual el soporte XFS no estuviera compilado como módulo pero si directamente (incluido en la imagen de kernel), para ello deberíamos comprobar el log de arranque: dmesg | grep –i xfs Una vez que tenemos soporte XFS en el kernel, necesitamos tener instalado el paquete xfsprogs, que contiene las herramientas necesarias para poder crear y gestionar el sistema de ficheros. Entre los comandos más importantes destacamos:

• mkfs.xfs: crea el sistema de ficheros XFS. • fsck.xfs: comprueba que la partición no tiene errores. • xfs_growfs: permite redimensionar las particiones XFS

aprovechando sus capacidades LVM. 1.2. Base de datos El portal almacenará cierta información de naturaleza relacional en la base de datos. Por ejemplo:

• Histórico de búsquedas realizadas (para su posterior explotación mediante informes)

• Comentarios • Información relacionada con las descargas • Noticias • Datos de los nodos de la federación • Tareas planificadas • Información sobre los Usuarios, Grupos y Roles • Etc.

Puesto que la capa de persistencia del portal se realiza a través del framework Hibernate 3, en principio la conexión a base de datos debería ser transparente de cara a los desarrollos. Al haberse programado las sentencias SQL en el lenguaje

45

HQL (propio de Hibernate), es éste quien realiza las traducciones para los diferentes dialectos de base de datos: Oracle, PostgreSQL, MySQL… 1.2.1. MySQL Con el fin de ilustrar una base de datos en el manual, se escoge MySQL por su carácter de software libre y su amplia instalación en la mayor parte de las comunidades. Las conexiones a la base de datos se realizarán desde el servidor Apache (ayuda MediaWiki) y desde el servidor del JBoss (portal Agrega).

Red De Almacenamiento

Red De Datos

Servidor de BBDDMYSQL

Red De Aplicación

DMZ

FIREWALLInterno

FIREWALL

Servidor AplicacionesJBOSS

Servidor WebAPACHE

:3306

:3306

Para el correcto funcionamiento del portal, se instalará la versión 5.0 o superior del servidor MySQL. El proceso completo de instalación no es objeto de este manual, ya que se encuentra ampliamente explicado tanto en el manual de instalación y operación de la plataforma así como en la documentación oficial de MySQL (ver referencias al final del documento). Sin embargo, vamos a destacar archivos de configuración importantes, procedimientos de creación de la base de datos y carga de los datos iniciales.

Servidor MySQL Una vez instalado el servidor MySQL (por ejemplo, versión 5.0.22 o superior) procederemos de la siguiente manera:

1. Revisamos la configuración del fichero /etc/my.cnf

Por defecto en la instalación de MySQL existen varios archivos de configuración de referencia para diferentes tamaños de bases de datos: my-small.cnf, my-medium.cnf, my-large.cnf, y my-huge.cnf. Asumiendo que tenemos 512 MBytes de memoria partiremos del fichero de configuración my-large.cnf. En el fichero my.cnf se configuran los siguientes parámetros importantes, a destacar:

46

# Example MySQL config file for large systems. # # This is for a large system with memory = 512M where the system runs mainly # MySQL. # # You can copy this file to # /etc/my.cnf to set global options, # mysql-data-dir/my.cnf to set server-specific options (in this # installation this directory is /var/lib/mysql) or # ~/.my.cnf to set user-specific options. # # In this file, you can use all long options that a program supports. # If you want to know which options a program supports, run the program # with the "--help" option. # The following options will be passed to all MySQL clients [client] #password = your_password port = 3306 socket = /var/lib/mysql/mysql.sock # Here follows entries for some specific programs # The MySQL server [mysqld] port = 3306 socket = /var/lib/mysql/mysql.sock skip-locking key_buffer = 2560M max_allowed_packet = 1M table_cache = 256 sort_buffer_size = 1M read_buffer_size = 1M read_rnd_buffer_size = 4M myisam_sort_buffer_size = 64M thread_cache_size = 8 query_cache_size= 16M # Try number of CPU's*2 for thread_concurrency thread_concurrency = 8 default-storage-engine=InnoDB max_connections=250 # Don't listen on a TCP/IP port at all. This can be a security enhancement, # if all processes that need to connect to mysqld run on the same host. # All interaction with mysqld must be made via Unix sockets or named pipes. # Note that using this option without enabling named pipes on Windows # (via the "enable-named-pipe" option) will render mysqld useless! # #skip-networking # Replication Master Server (default) # binary logging is required for replication log-bin=mysql-bin # required unique id between 1 and 2^32 - 1 # defaults to 1 if master-host is not set # but will not function as a master if omitted server-id = 1

47

# Replication Slave (comment out master section to use this) # # To configure this host as a replication slave, you can choose between # two methods : # # 1) Use the CHANGE MASTER TO command (fully described in our manual) - # the syntax is: # # CHANGE MASTER TO MASTER_HOST=<host>, MASTER_PORT=<port>, # MASTER_USER=<user>, MASTER_PASSWORD=<password> ; # # where you replace <host>, <user>, <password> by quoted strings and # <port> by the master's port number (3306 by default). # # Example: # # CHANGE MASTER TO MASTER_HOST='125.564.12.1', MASTER_PORT=3306, # MASTER_USER='joe', MASTER_PASSWORD='secret'; # # OR # # 2) Set the variables below. However, in case you choose this method, then # start replication for the first time (even unsuccessfully, for example # if you mistyped the password in master-password and the slave fails to # connect), the slave will create a master.info file, and any later # change in this file to the variables' values below will be ignored and # overridden by the content of the master.info file, unless you shutdown # the slave server, delete master.info and restart the slaver server. # For that reason, you may want to leave the lines below untouched # (commented) and instead use CHANGE MASTER TO (see above) # # required unique id between 2 and 2^32 - 1 # (and different from the master) # defaults to 2 if master-host is set # but will not function as a slave if omitted #server-id = 2 # # The replication master for this slave - required #master-host = <hostname> # # The username the slave will use for authentication when connecting # to the master - required #master-user = <username> # # The password the slave will authenticate with when connecting to # the master - required #master-password = <password> # # The port the master is listening on. # optional - defaults to 3306 #master-port = <port> # # binary logging - not required for slaves, but recommended #log-bin=mysql-bin # Point the following paths to different dedicated disks #tmpdir = /tmp/ #log-update = /path-to-dedicated-directory/hostname

48

# Uncomment the following if you are using BDB tables #bdb_cache_size = 64M #bdb_max_lock = 100000 # Uncomment the following if you are using InnoDB tables innodb_data_home_dir = /var/lib/mysql/ innodb_data_file_path = ibdata1:100M:autoextend innodb_log_group_home_dir = /var/lib/mysql/ innodb_log_arch_dir = /var/lib/mysql/ # You can set .._buffer_pool_size up to 50 - 80 % # of RAM but beware of setting memory usage too high innodb_buffer_pool_size = 256M innodb_additional_mem_pool_size = 20M # Set .._log_file_size to 25 % of buffer pool size #innodb_log_file_size = 64M innodb_log_file_size = 200M innodb_log_buffer_size = 8M innodb_flush_log_at_trx_commit = 1 innodb_lock_wait_timeout = 50 [mysqldump] quick max_allowed_packet = 16M [mysql] no-auto-rehash # Remove the next comment character if you are not familiar with SQL #safe-updates [isamchk] key_buffer = 128M sort_buffer_size = 128M read_buffer = 2M write_buffer = 2M [myisamchk] key_buffer = 128M sort_buffer_size = 128M read_buffer = 2M write_buffer = 2M [mysqlhotcopy] interactive-timeout

2. Arrancamos el demonio En los casos de Linux, generalmente se ha creado un script de arranque en /etc/init.d/. Ejecutamos el siguiente comando: /etc/init.d/mysqld start 3. Agregamos una contraseña para el usuario root: mysqladmin -u root password 'password'

4. Nos conectamos con el usuario root al servidor MySQL mysql -u root –p –h <ip_mysql_server> 5. Creamos la base de datos para Agrega

49

create database agrega;

6. Creamos el usuario agrega_user con permisos de inserción, modificación, eliminación de registros y consulta de las tablas de la base de datos Agrega:

grant insert, update, delete, select on agrega.* to agrega_user@'somehost' identified by 'password';

flush privileges;

Donde somehost es la dirección IP o subred (por ejemplo: 10.1.2.*) desde la cual queremos dejar acceder al usuario y donde password es la contraseña. Para mayor seguridad especificaremos la IP desde la cual accede el servidor JBoss.

7. Creamos la base de datos para la ayuda (Mediawiki) create database wikidb; 8. Creamos el usuario wiki_user con acceso de escritura, modificación,

borrado y consulta de las tablas de la base de datos wikidb: grant insert, update, delete, select on wikidb.* to wiki_user@'somehost' identified by 'password';

flush privileges;

Especificaremos en somehost la dirección IP desde la cual accede el servidor Apache o la subred en la cual se encuentran los servidores Apaches (en caso de tener más de uno).

Base de datos: Agrega Habiendo creado ya la base de datos y el usuario agrega_user, durante la instalación del nodo se ejecutaron los siguientes scripts SQL:

• CrearTablas.sql El cometido del script consiste en crear toda la estructura de tablas necesarias para el correcto funcionamiento del portal Agrega, además de crear los índices y las contraints necesarias.

• CargarDatos.sql

Una vez creadas todas las tablas, índices y restricciones, se procede a hacer una carga inicial de datos necesarios (idiomas, localización de los índices, FAQs iniciales, etc).

Los comandos SLQ empleados fueron:

mysql –u root –p –h <ip_mysql_server> use agrega; source CrearTablas.sql; source CargarDatos.sql; commit;

Es necesario conectar con el usuario root (o cualquier otro con privilegios para la creación de tablas) ya que el usuario agrega_user únicamente tiene permisos de inserción, modificación, eliminación y consulta de registros pero no de creación o borrado de tablas.

50

Para comprobar que la creación del usuario y las inserciones han sido correctas, podemos ejecutar (desde la máquina que se autorizó al crear al usuario si tiene instalado el cliente mysql) los siguientes comandos: mysql –u agrega_user –p –h <ip_mysql_server> use agrega; show tables; Base de datos: Ayuda Una vez creados tanto la base de datos wikidb como el usuario wiki_user, procedemos a insertar tanto las tablas como los contenidos de las mismas a partir de un dump generado: mysql -u root -p –h <ip_mysql_server> wikidb < wikidb.sql De nuevo, al igual que en el caso anterior, debemos ejecutar la inserción del dump con el usuario root puesto que wiki_user no tiene permisos de creación / borrado de tablas. Para comprobar que la creación del usuario y las inserciones han sido correctas, podemos ejecutar (desde la máquina que se autorizó al crear al usuario si tiene instalado el cliente mysql) los siguientes comandos: mysql –u wiki_user –p –h <ip_mysql_server> use wikidb; show tables; 1.3. Autenticación LDAP El modo de acceso a la aplicación y a los distintos módulos funcionales se realizará a través del navegador web utilizando los protocolos HTTP y HTTPS para la autenticación del usuario en el portal. El sistema pedirá un login y una clave al usuario que validará mediante la operación Bind contra un directorio LDAP, que puede ser propio de la CCAA o interno del nodo, en donde residirá por cada usuario un identificador único y una clave cifradas con la función SHA-1. Si la autenticación es correcta, el portal continuará con la carga adquiriendo los roles de la base de datos (para la autorización de los accesos a los diferentes componentes del portal). En caso contrario, se deniega el login y se notifica al usuario el error. Se controlará el tiempo de sesión (timeout de sesión) del usuario, de tal manera que cuando el usuario no mantenga actividad durante un periodo configurable entre 20 y 30 minutos, se le cerrará la sesión y se le obligará a autenticarse de nuevo para reiniciar la sesión. Desde la plataforma Agrega, únicamente desde el servidor de aplicaciones JBoss se efectuarán las conexiones al servidor LDAP, típicamente escuchando en el puerto 389 tal y como muestra la siguiente figura:

51

Si existieran varios servidores de aplicación JBoss en cluster, todos y cada uno de ellos establecerían la conexión con el servidor de directorios LDAP. 1.3.1. OpenLDAP La información relativa a los usuarios utilizada por el proceso de autenticación se almacenará en un directorio LDAP. Si la CCAA tuviera instalado un LDAP versión 3 se podría utilizar el mismo. En el caso en el cual no se deseara reutilizar un LDAP existente o se prefiriera instalar un nuevo LDAP, recomendamos OpenLDAP 2.2.13 o superior. El proceso de instalación completo viene descrito en el manual de instalación y operación de la plataforma y en la referencia (página oficial). Una vez instalado OpenLDAP, configuramos el servidor mediante el archivo de configuración presente en /etc/openldap/slapd.conf: # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema # Allow LDAPv2 client connections. This is NOT the default. allow bind_v2 pidfile /var/run/slapd.pid argsfile /var/run/slapd.args loglevel 256 ####################################################################### # ldbm and/or bdb database definitions ####################################################################### database bdb suffix "dc=agrega,dc=<nodo>,dc=es" rootdn "cn=Administrador,dc=agrega,dc=<nodo>,dc=es" # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged.

52

rootpw {password} # rootpw {crypt}ijFYNcSNctBYg # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap # Indices to maintain for this database index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub

• allow bind_v2 Permitimos conexiones por parte de clientes usando LDAPv2.

• suffix "dc=agrega,dc=<nodo>,dc=es" Especificamos el sufijo DN (Distinguished Name) para las consultas que será pasado a la base de datos del LDAP. Se pueden especificar múltiples sufijos mediante múltiples líneas y al menos una entrada es requerida por cada definición de base de datos.

• rootdn "cn=Administrador,dc=agrega,dc=<nodo>,dc=es" Mediante esta directiva especificamos el DN que no se encuentra sujeto a controles de acceso o restricciones administrativos para operaciones sobre la base de datos. Como norma general cambiaremos <nodo> por el nombre del nodo de la CCAA.

• rootpw {password} Especificamos la contraseña para el DN rootdn. Se puede especificar en texto

plano: rootpw secret

Aunque también se permite dar la password generada mediante la función hash con el comando slappaswd:

slappasswd -s secret Ejemplo: rootpw {SSHA}ZKKuqbEKJfKSXhUbHG3fG8MDn9j1v4QN

• directory /var/lib/ldap Mediante esta directiva especificamos el directorio donde se almacenan los ficheros BDB que contienen la base de datos y los índices asociados.

Una vez configurado el servicio de LDAP procedemos crear la base de datos mediante el método off-line. Para ello empleamos el comando: slapadd -l cargaInicial.ldif El contenido de la cargaInicial.ldif es:

53

dn: dc=agrega,dc=indra,dc=es dc: agrega objectClass: dcObject objectClass: organization o: agrega dn: cn=Administrador,dc=agrega,dc=indra,dc=es objectClass: organizationalRole cn: Administrador dn: ou=users,dc=agrega,dc=indra,dc=es ou: users objectClass: top objectClass: organizationalUnit dn: dc=<sitio>,dc=agrega,dc=indra,dc=es dc: <sitio> objectClass: dcObject objectClass: organization o: <sitio> dn: ou=usuarios,dc=<sitio>,dc=agrega,dc=indra,dc=es ou: usuarios objectClass: top objectClass: organizationalUnit dn: cn=administrador,ou=usuarios,dc=<sitio>,dc=agrega,dc=indra,dc=es userPassword:: e1NIQX1OV29aSzNrVHNFeFVWMDBZd28xRzVqbFVLS3M9 objectClass: top objectClass: person sn: Administrador admin cn: administrador dn: ou=rol,dc=<sitio>,dc=agrega,dc=indra,dc=es ou: rol objectClass: top objectClass: organizationalUnit En donde se sustituirá <sitio> por el nombre del nodo de la CCAA. Gráficamente podemos ver el contenido del LDIF:

Para comprobar el correcto funcionamiento de LDAP podemos usar un navegador de LDAP como son LDAP Browser y Apache Directory Studio. La conexión se verá definida por los siguientes parámetros:

• IP del servidor LDAP

54

• Puerto de conexión: normalmente 389 • Bind DN: cn=Administrador,dc=agrega,dc=indra,dc=es • Bind Password: la contraseña que hemos especificado.


2 h


2. Capa de aplicación En la capa de aplicación encontramos 3 componentes fundamentales:

• JDK 1.6: Es necesario disponer de la versión JDK 1.6 o superior para poder ejecutar tanto el servidor de aplicaciones como la galería de imágenes.

• JBossAS: el portal Agrega (desarrollo J2EE 1.4) se puede desplegar sobre el servidor de aplicaciones JBoss. Modificando manualmente configuraciones y agregando un servidor de colas JMS como Apache ActiveMQ también se podría desplegar sobre Tomcat.

• Galería de imágenes: cada vez que se carga un ODE en la plataforma, se genera una captura de pantalla (previsualización o thumbnail) del recurso, para ello, se hace uso de diversas herramientas de software libre tales como ffmpeg, convert, firefox…

2.1. JDK 1.6 La versión mínima para ejecutar la plataforma es de Java 1.5, pero por razones de rendimiento y actualizaciones se aconseja la utilización de la JDK 1.6u6 o superior. Una vez instalada es importante modificar el perfil del usuario que arrancará el jboss configurando las siguientes variables de entorno:

1. Se recomienda crear el enlace simbólico /opt/jdk que apunte al directorio real donde se ha instalado la JDK con el fin de independizar las variables de entorno de la versión de JDK instalada.

Por ejemplo: ln -s /usr/java/jdk1.6.0_06/ jdk

2. Editamos el /etc/profile añadiendo las dos exportaciones siguientes:

export JAVA_HOME=/opt/jdk export PATH=$PATH:$JAVA_HOME/bin

Para comprobar que se ha instalado la JDK correctamente, basta con salir de la shell, hacer de nuevo logging en el sistema y ejecutar el comando:

java -version

55

2.1.1. Configurando Java HotSpot VM En las referencias especificadas para JDK se describen todos los parámetros y los efectos producidos sobre la JVM, entre los más importantes destacamos:

Parámetro Descripción -Xms Establecemos el tamaño mínimo de pila -Xmx Establecemos el tamaño máximo de pila

-XX:MaxPermSize Tamaño de la generación permanente. Se necesita para la carga de los metadatos de las clases.

-XX:ThreadStackSize Tamaño de la pila de threads (en KBytes) En cuanto a la memoria, veamos con un poco más de detalle la importancia de escoger correctamente los valores -Xms y –Xmx:

En la figura apreciamos la diferencia entre el espacio reservado y el espacio virtual de la pila. Al arrancar la JVM, todo el espacio de la pila es reservado. El tamaño del espacio reservado se especifica mediante la opción –Xmx. Si el valor de –Xms es inferior que el valor –Xmx, no todo el espacio reservado es inmediatamente volcado a la JVM. El espacio no volcado se denomina “virtual” en la figura. Las diferentes partes de la pila (permanent generation, tenured generation y young generation) pueden crecer mientras lo necesiten hasta el límite de cada espacio virtual. En la inicialización de la JVM, el tamaño máximo de espacio es virtualmente reservado pero no reservado de la memoria física a menos que se necesite. El rango de espacio completo reservado por un objeto en memoria se puede dividir dentro de la young generation y tenured generation. La young generation consiste en el eden más dos espacios survivor. Los objetos cuando son creados son inicialmente ubicados en el eden. Un espacio survivor está vacío todo el tiempo, y sirve como destino entre la copia de colecciones de objetos vivos en el eden y el otro espacio survivor. Los objetos se copian entre los espacios survivor hasta que son lo suficientemente viejos, momento en el cual son copiados a la tenured generation.

56

Existe una tercera generación denominada permanent generation. En ella se mantienen los datos necesarios para la JVM que describen los objetos que no tienen una equivalencia directa en el lenguaje Java, por ejemplo, los objetos que describen clases y métodos se almacenan en la permanent generation. Así pues, el tamaño total ocupado por la JVM será el valor Xmx + MaxPermSize (dicho valor, nunca debe superar la memoria física real del servidor para evitar la swap). Con respecto al recolector de basura (garbage collector, GC), en la plataforma 1.5 de Java se agregan 3 colectores adicionales. Cada uno está implementado o para enfatizar el throughput de la aplicación o para minimizar los tiempos de pausa por la recolección de basura. Por defecto, se emplea el Serial collector con el cual la recolección se realiza en un único thread y es ejecutado en serie junto con la aplicación. Los otros recolectores3 posibles son:

1. Throughput collector: emplea una version paralela del recolector de basura de la memoria young generation. Para habilitarlo hay que emplear la opción –XX:+UseParallelGC desde la línea de comandos. La memoria tenured generation es recolectada con el recolector serie estándar.

2. Concurrent low pause collector: se habilita usando la opción –Xincgc o -XX:+UseConcMarkSweepGC desde la línea de comandos. Se emplea para recolectar la tenured generation y lo realiza concurrentemente con la ejecución de la aplicación. La aplicación se ve pausada cortos periodos de tiempo durante la recolección.

3. Incremental low pause collector (train): no ha cambiado desde la versión 1.4.2 y actualmente no se encuentra en desarrollo activo (no será soportado en futuras releases probablemente). Para usarlo se habilita mediante la propiedad -XX:+UseTrainGC.

Las recomendaciones oficiales de Sun para el uso de los distintos recolectores son las siguientes:

Garbage Collector Recomendación

Throughput collector

Se emplea cuando se desea mejorar el rendimiento de la aplicación y disponemos de múltiples procesadores. Las recolecciones mayores o completas son iguales que en el recolector serie, sin embargo, en un host con N CPUs, usará N hilos recolectores para las recolecciones menores o parciales.

Concurrent low pause collector

Si la aplicación puede permitirse compartir los recursos de procesadores con el recolector mientras se está ejecutando podemos beneficiarnos de menores pausas durante la recolección. Típicamente las aplicaciones que tienen datos que permanecen en memoria durante bastante tiempo y con uno o dos procesadores.

Incremental low pause collector

El modo incremental se consigue gracias a que el trabajo realizado concurrentemente por el recolector se divide en pequeñas porciones de tiempo programadas entre las recolecciones de la memoria young generation. Es útil cuando tenemos aplicaciones que necesitan pausas cortas y se ejecutan en máquinas con sólo 1 o 2 procesadores.

2.2. Servidor de Aplicaciones JBossAS El portal Agrega es un desarrollo J2EE que puede ser desplegado en cualquier

57

contenedor de aplicaciones J2EE compatible (versión 1.4). Debido a las características técnicas, la comunidad open source que existe a su alrededor, la estabilidad mostrada en entornos de producción y las continuas mejoras y evoluciones hemos seleccionado a JBoss como el servidor de aplicaciones de referencia. A lo largo de la sección, se hará referencia a $JBOSS_HOME como el directorio donde se ha instalado el jboss; por ejemplo: /opt/jboss-4.0.5.GA/. 2.2.1. Comprobaciones previas del sistema Apertura de ficheros Se comprueba que no exista límite de apertura de ficheros (open files) con el comando ulimit -a Si existe alguna limitación se deben agregar las siguientes líneas en el fichero /etc/limits.conf: * soft nofile 65530 * hard nofile 65535 Máximo número de sockets de red Para comprobar el valor actual empleamos el siguiente comando: sysctl -a |grep -i somaxconn Si el límite son 128 deberemos ampliarlo a un valor superior a 1024 (se recomienda 4096). Para ello, en el fichero /etc/sysctl.conf agregamos la línea: net.core.somaxconn = 4096 También podemos cambiar en caliente el valor (para no tener que reiniciar el servidor) mediante el comando: sysctl –w net.core.somaxconn=4096 Es necesario reiniciar el servidor para que ambos cambios efectuados sean tenidos en cuenta. Usuario y grupo jboss Se recomienda que el proceso de JBossAS sea lanzado por un usuario (diferente de root) con permisos adecuados, así garantizaremos que el usuario pueda escribir en los diferentes directorios necesarios para el correcto funcionamiento del portal. Los pasos a dar serían los siguientes:

1. Creamos el grupo jboss groupadd jboss

2. Creamos el usuario jboss en el grupo primario jboss (-g) con la consola bash

(-s), creando un home para el usuario si no existe (-m) en el home /opt/jboss (-d) useradd -g jboss -s /bin/bash -m -d /opt/jboss jboss

58

3. Establecemos un password para el usuario jboss

passwd jboss Para comprobar que los pasos se han realizado correctamente, podemos probar a entrar en el host con el usuario jboss y la password establecida. 2.2.2. Directorio $JBOSS_HOME/bin. Scripts de arranque Dentro del directorio bin, JBoss almacena los scripts de arranque tanto para sistemas Linux como para Windows (run.sh y run.bat respectivamente). run.conf Adicionalmente, existe un fichero denominado run.conf que contiene los parámetros a pasar a la máquina virtual de Java (JVM) para el arranque del JBoss. En concreto, la línea que nos interesa es: if [ "x$JAVA_OPTS" = "x" ]; then JAVA_OPTS="-Xms128m -Xmx512m -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000" fi Completamos dicha línea, eliminando los parámetros -Dsun.rmi.dgc.* y agregando otros nuevos, quedando así: if [ "x$JAVA_OPTS" = "x" ]; then JAVA_OPTS="-Xms512m –Xmx1536m -XX:MaxPermSize=786m -Djava.awt.headless=true" fi Es fundamental configurar correctamente los parámetros de la JVM que arrancará JBoss, ya que estamos indicando parámetros tales como las reservas de memoria, el comportamiento de AWT, etc. Una vez comprendido como la JVM hace uso de la memoria reservada, podemos aplicar unas recomendaciones prácticas de los valores en función de la memoria total del sistema (asumiendo que el mayor consumo de memoria en el servidor será el JBoss y no hay otros servicios que hagan un uso intensivo de memoria como pueden ser una BD, un LDAP…).

Memoria física Servidor -Xms -Xmx -XX:MaxPermSize 1 GB 256m 512m 384m 2 GB 512m 1024m 768m

2.5 GB 512m 1536m 768m 4 GB 512m 2560m 768m

El portal, una vez cargado todos los módulos, con menos de 2 GB de RAM tendrá que hacer uso de la memoria SWAP con la consiguiente pérdida de rendimiento que ello implica.

59

/etc/init.d/jboss y run.sh Al realizar la instalación, en los sistemas Linux, en el directorio bin se encuentra el fichero “jboss_init_redhat.sh”, fichero que se suele copiar al directorio /etc/init.d/ para el arranque y parada del servidor. En el script, se añade una línea para que lea el fichero /etc/jboss.conf que contiene las siguientes líneas: JBOSS_HOME=/opt/jboss JBOSS_USER=jboss El contenido del script /etc/init.d/jboss es el siguiente: #!/bin/sh # # $Id: jboss_init_redhat.sh 46554 2006-07-28 10:29:13Z dimitris $ # # JBoss Control Script # # To use this script run it as root - it will switch to the specified user # # Here is a little (and extremely primitive) startup/shutdown script # for RedHat systems. It assumes that JBoss lives in /usr/local/jboss, # it's run by user 'jboss' and JDK binaries are in /usr/local/jdk/bin. # All this can be changed in the script itself. # # Either modify this script for your requirements or just ensure that # the following variables are set correctly before calling the script. #define where jboss is - this is the directory containing directories log, bin, conf etc . /etc/jboss.conf JBOSS_HOME=${JBOSS_HOME:-"/opt/jboss"} #define the user under which jboss will run, or use 'RUNASIS' to run as the current user JBOSS_USER=${JBOSS_USER:-"jboss"} #make sure java is in your path JAVAPTH=${JAVAPTH:-"/opt/jdk/bin"} #configuration to use, usually one of 'minimal', 'default', 'all' JBOSS_CONF=${JBOSS_CONF:-"default"} #bind address for jboss services, by default bind to *all* NICs JBOSS_HOST=${JBOSS_HOST:-"0.0.0.0"} #define the classpath for the shutdown class JBOSSCP=${JBOSSCP:-"$JBOSS_HOME/bin/shutdown.jar:$JBOSS_HOME/client/jnet.jar"} #define the script to use to start jboss JBOSSSH=${JBOSSSH:-"$JBOSS_HOME/bin/run.sh -c $JBOSS_CONF -b $JBOSS_HOST"} if [ "$JBOSS_USER" = "RUNASIS" ]; then SUBIT="" else SUBIT="su - $JBOSS_USER -c " fi if [ -n "$JBOSS_CONSOLE" -a ! -d "$JBOSS_CONSOLE" ]; then

60

# ensure the file exists touch $JBOSS_CONSOLE if [ ! -z "$SUBIT" ]; then chown $JBOSS_USER $JBOSS_CONSOLE fi fi if [ -n "$JBOSS_CONSOLE" -a ! -f "$JBOSS_CONSOLE" ]; then echo "WARNING: location for saving console log invalid: $JBOSS_CONSOLE" echo "WARNING: ignoring it and using /dev/null" JBOSS_CONSOLE="/dev/null" fi #define what will be done with the console log JBOSS_CONSOLE=${JBOSS_CONSOLE:-"/dev/null"} JBOSS_CMD_START="cd $JBOSS_HOME; $JBOSSSH" JBOSS_CMD_STOP=${JBOSS_CMD_STOP:-"java -classpath $JBOSSCP org.jboss.Shutdown --shutdown"} if [ -z "`echo $PATH | grep $JAVAPTH`" ]; then export PATH=$PATH:$JAVAPTH fi if [ ! -d "$JBOSS_HOME" ]; then echo JBOSS_HOME does not exist as a valid directory : $JBOSS_HOME exit 1 fi echo JBOSS_CMD_START = $JBOSS_CMD_START case "$1" in start) cd $JBOSS_HOME/bin if [ -z "$SUBIT" ]; then eval $JBOSS_CMD_START >${JBOSS_CONSOLE} 2>&1 & else $SUBIT "$JBOSS_CMD_START >${JBOSS_CONSOLE} 2>&1 &" fi ;; stop) if [ -z "$SUBIT" ]; then $JBOSS_CMD_STOP else $SUBIT "$JBOSS_CMD_STOP" fi ;; restart) $0 stop $0 start ;; *) echo "usage: $0 (start|stop|restart|help)" esac Se han destacado 4 líneas en negrita:

• ./etc/jboss.conf

61

Especificamos que se lea el fichero con las variables de entorno ya comentadas anteriormente.

• JAVAPTH=${JAVAPTH:-"/opt/jdk/bin"}

Indicamos el directorio donde se encuentran los binarios de la JDK.

• JBOSSSH=${JBOSSSH:-"$JBOSS_HOME/bin/run.sh -c $JBOSS_CONF -b $JBOSS_HOST"} Ejecutamos el script run.sh con los parámetros –c default (valor de la variable JBOSS_CONF por defecto) y con el parámetro –b 0.0.0.0 (bind en todas las direcciones IPs de la máquina). Si se deseara que JBoss solo escuchara en una interfaz de red de entre todas las disponibles de la máquina deberíamos especificarle la variable de entorno JBOSS_HOST en el fichero /etc/jboss.conf.

• JBOSS_CMD_START="cd $JBOSS_HOME; $JBOSSSH"

Es importante destacar que se ha modificado la línea para que el path desde el cual se ejecuta el JBoss sea el propio $JBOSS_HOME y no $JBOSS_HOME/bin como especifica el fichero original de la distribución de JBoss.

2.2.3. Ficheros de configuración de JBoss Los ficheros más relevantes para la correcta configuración de la plataforma Agrega se establecen del siguiente modo: Configuración de los conectores de JBoss: HTTP y AJP En el fichero $JBOSS_HOME/server/default/deploy/jbossweb-tomcat55.sar/server.xml se configuran los parámetros de los conectores HTTP y AJP:  <Connector port="8080" address="${jboss.bind.address}" maxThreads="250" strategy="ms" maxHttpHeaderSize="8192" emptySessionPath="true" enableLookups="false" redirectPort="8443" acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true"/>  <Connector port="8009" address="${jboss.bind.address}" emptySessionPath="true" enableLookups="false" redirectPort="8443" protocol="AJP/1.3" maxThreads="400" connectionTimeout="600000"/> Con respecto al conector AJP, que es quien recibirá las peticiones de Apache, en la wiki oficial de JBoss especificada en las referencias aconsejan una configuración de 200 threads por CPU, por lo que para una máquina con 2 CPUs el valor recomendado sería maxThreads=”400”. El tiempo máximo de conexión debe ser igual al valor configurado en los workers de Apache (se describirá en detalle en la sección de Apache). Veamos los parámetros más importantes de configuración de ambos conectores:

62

HTTP

Parámetro Descripción Valor por defecto

acceptCount

La longitud máxima de la cola de conexiones entrantes cuando todos los hilos que atienden peticiones están en uso. Cualquier petición de conexión que se reciba cuando todos los threads estén en uso será rechazada.

100

connectionTimeout El número de milisegundos que el conector esperará, después de aceptar una conexión, hasta que se le solicite la petición de URI.

60.000 (60 sg)

disableUploadTimeout Este flag permite al contenedor de servlets usar un tiempo máximo de espera diferente mientras se esta ejecutando el servlet.

true

maxHttpHeaderSize Define el tamaño máximo de la cabecera HTTP de la petición y de la respuesta (especificado en bytes).

4096 bytes (4

KB)

maxKeepAliveRequests

Máximo número de peticiones HTTP que pueden ser encoladas hasta que el servidor cierra la conexión. Si se especifica un valor de 1 se desactivará el HTTP/1.0 keep-alive y HTTP/1.1 keep-alive y pipelining. Si se especifica el valor -1 se permitirán infinitas peticiones encoladas.

100

maxSpareThreads

El máximo número de hilos procesadores de peticiones sin usar que pueden existir hasta que el pool de hilos comienza a parar los hilos innecesarios.

50

maxThreads

El máximo número de hilos procesadores de peticiones creados por el conector. Determina el máximo número de peticiones simultáneas que pueden ser procesadas.

200

minSpareThreads Número de hilos procesadores de peticiones creados cuando el conector arranca. 4

port El puerto TCP sobre el cual el conector creará el socket servidor de Java esperando peticiones entrantes.

-

AJP

Parámetro Descripción Valor por defecto

connectionTimeout El número de milisegundos que el conector esperará, después de aceptar una conexión, hasta que se le solicite la petición de URI.

Infinito

maxSpareThreads El máximo número de hilos procesadores de peticiones sin usar que pueden existir hasta que el pool de hilos comienza a parar los hilos innecesarios.

50

maxThreads

El máximo número de hilos procesadores de peticiones creados por el conector. Determina el máximo número de peticiones simultáneas que pueden ser procesadas.

200

minSpareThreads Número de hilos procesadores de peticiones creados cuando el conector arranca. 4

port El puerto TCP sobre el cual el conector creará el socket servidor de Java esperando peticiones entrantes.

-

63

Datasources Puesto que cada módulo que hace uso de la base de datos podría desplegarse en un servidor JBoss diferente, atacando a una base de datos distinta, cada módulo con acceso a base de datos tiene su propio datasource definido. En JBoss los ficheros datasources se definen dentro del directorio deploy ($JBOSS_HOME/server/default/deploy) y siempre acaban con el sufijo “–ds.xml”. En nuestro caso, durante la instalación se habrá generado un fichero denominado “<sitio>-ds.xml” donde <sitio> será el nombre de la CCAA. El contenido del fichero es el siguiente: <?xml version="1.0" encoding="UTF-8"?> <datasources> <local-tx-datasource> <jndi-name>jdbc/planificadorDS</jndi-name> <connection-url>jdbc:mysql://ip_basedatos:3306/ccaa</connection-url> <driver-class>com.mysql.jdbc.Driver</driver-class> <user-name>usuario</user-name> <password>password</password> <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter</exception-sorter-class-name>    <metadata> <type-mapping>mySQL</type-mapping> </metadata> </local-tx-datasource> … Los parámetros a configurar son los destacados en negrita:

• jndi-name: Nombre JNDI con el que se publica la conexión a base de datos. • connection-url: URL que especifica la conexión al servidor de base de

datos. En el caso de MySQL es: jdbc:mysql://ip_basedatos:puerto/base_datos Para PostgreSQL es: jdbc:postgresql:// ip_basedatos: puerto/base_datos

• driver-class: driver empleado para la conexión JDBC a la base de datos. Para MySQL es com.mysql.jdbc.Driver Para PostgreSQL es org.postgresql.Driver

• user-name: usuario de acceso a la base de datos. • password: contraseña de acceso a la base de datos.

En el directorio $JBOSS_HOME/docs/examples/jca/ vienen ejemplos de datasources para la mayoría de las bases de datos.

64

En concreto, si la instalación se realiza en un único JBoss se definirán los siguientes datasources asociados a los siguientes nombres JNDI: <jndi-name>jdbc/planificadorDS</jndi-name> <jndi-name>jdbc/modificadorDS</jndi-name> <jndi-name>jdbc/contenidosportalDS</jndi-name> <jndi-name>jdbc/publicacionDS</jndi-name> <jndi-name>jdbc/LocalizadorDS</jndi-name> <jndi-name>jdbc/indexadorDS</jndi-name> <jndi-name>jdbc/buscarDS</jndi-name> <jndi-name>jdbc/adminusuariosDS</jndi-name> <jndi-name>jdbc/auditoriaDS</jndi-name> <jndi-name>jdbc/valoracionDS</jndi-name> <jndi-name>jdbc/driDS</jndi-name> Para conseguir que las clases del driver JDBC de MySQL se encuentren disponibles para JBoss, es necesario copiar el fichero mysql-connector-java-version.bin.jar al directorio lib ($JBOSS_HOME/server/default/lib). Colas JMS El portal Agrega, hace uso de colas JMS para las comunicaciones asíncronas en los módulos. JBoss integra JBossMQ: varios servicios que trabajando juntos proveen servicios a nivel de la JMS API a las aplicaciones clientes. Los principales servicios a tener en cuenta son:

1. Invocation Layer Servicios responsables de la gestión de los protocolos de comunicación (bidireccionales) que los clientes usan para enviar y recibir los mensajes concurrentemente. Cada servicio IL se asocial a una factoria de conexiones JMS especificada bajo el árbol JNDI. JBossMQ provee los siguientes ILs:

• UIL2 IL: Unified Invocation Layer version 2(UIL2). • JVM IL: Java Virtual Machine (JVM) Invocation Layer. Desarrollado

para evitar la sobrecarga TCP/IP cuando el cliente JMS está siendo ejecutado en la misma máquina virtual que el servidor de colas (nuestro caso). El servicio IL usa llamadas directas a métodos desde el servidor para servir a los clientes. Se incrementa así la eficiencia al no crearse ningún socket ni hilos para la comunicación. Configuraremos así las colas para el portal Agrega.

• HTTP IL: HTTP Invocation Layer (HTTPIL) permite el acceso del servicio JBossMQ mediante los protocolos HTTP y HTTPs.

2. Security Manager

Servicio que controla el acceso a los destinos a partir de una lista de control de acceso.

3. Destination Manager Servicio que mantiene todos los destinos que se han creado.

4. Persistence Manager Servicio que se encarga de la persistencia de los mensajes almacenados en las colas.

65

5. Destinations: Queues y Topics

Un destino no es más que un objeto en el servidor JBossMQ que usan los clientes para enviar y recibir los mensajes. Hay 2 tipos de destinos conforme a la API JMS: Queue y Topics. Las referencias a los destinos creados se almacenan en el árbol JNDI.

• Queues: las colas siguen el paradigma punto a punto. Si un mensaje entra en una cola y hay múltiples recibidores escuchando, sólo uno consumirá el mensaje (al leer el mensaje éste sale de la cola).

• Topics: se basan en el paradigma de la publicación/subscripción. Cuando un cliente publica un mensaje al destino Topic, el mensaje es entregado a todos y cada uno de los subscriptores de la cola (clientes que se encuentren subscritos a la cola).

El portal de Agrega, necesita que existan los siguientes destinos en el fichero $JBOSS_HOME/server/default/deploy/jms/jbossmq-destinations-service.xml: … <mbean code="org.jboss.mq.server.jmx.Queue" name="jboss.mq.destination:service=Queue,name=A"> <depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends> </mbean> <mbean code="org.jboss.mq.server.jmx.Queue" name="jboss.mq.destination:service=Queue,name=B"> <depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends> </mbean> <mbean code="org.jboss.mq.server.jmx.Queue" name="jboss.mq.destination:service=Queue,name=C"> <depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends> </mbean> <mbean code="org.jboss.mq.server.jmx.Queue" name="jboss.mq.destination:service=Queue,name=D"> <depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends> </mbean> <mbean code="org.jboss.mq.server.jmx.Queue" name="jboss.mq.destination:service=Queue,name=auditarQueue"> <depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends> </mbean> <mbean code="org.jboss.mq.server.jmx.Queue" name="jboss.mq.destination:service=Queue,name=modificador"> <depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends> </mbean> <mbean code="org.jboss.mq.server.jmx.Queue" name="jboss.mq.destination:service=Queue,name=ex"> <depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends> </mbean> …

66

En donde apreciamos que además de los destinos ya existentes por parte de JBoss, se han agregado los destinos (colas Queue) de auditarQueue y modificador. Para que los desarrollos puedan emplear el servicio JVM-IL es necesario agregar un alias en el fichero $JBOSS_HOME/server/default/deploy/jms/jvm-il-service.xml, quedando el fichero así: <?xml version="1.0" encoding="UTF-8"?>  <server>  <mbean code="org.jboss.mq.il.jvm.JVMServerILService" name="jboss.mq:service=InvocationLayer,type=JVM"> <depends optional-attribute-name="Invoker">jboss.mq:service=Invoker</depends> <attribute name="ConnectionFactoryJNDIRef">java:/ConnectionFactory</attribute> <attribute name="XAConnectionFactoryJNDIRef">java:/XAConnectionFactory</attribute> <attribute name="PingPeriod">0</attribute> </mbean> <mbean code="org.jboss.naming.NamingAlias" name="jboss.mq:service=InvocationLayer,type=JVM"> <attribute name="FromName">JVMILConnectionFactory</attribute> <attribute name="ToName">java:/ConnectionFactory</attribute> <depends>jboss:service=Naming</depends> </mbean> </server> Alias en directorios Hay dos módulos (RSS y la galería de imágenes) que necesitan acceder a los recursos que se publican en la carpeta compartida. Puesto que se acceden directamente desde el JBoss (no pasando por Apache), es necesario definir manualmente 2 alias para que accedan al recurso real. En el fichero: $JBOSS_HOME/server/default/deploy/jbossweb-tomcat55.sar/server.xml definimos los siguientes dos alias (rss y galeriaimg): <Host name="localhost" autoDeploy="false" deployOnStartup="false" deployXML="false" configClass="org.jboss.web.tomcat.security.config.JBossContextConfig" > <Context path="/rss" appBase="" docBase="/export/ccaa/<sitio>/uploads/rss" debug="99" reloadable="true"> </Context> <Context path="/galeriaimg" appBase="" docBase="/export/ccaa/<sitio>/uploads/galeriaimg/<sitio>" debug="99" reloadable="true">

67

</Context> Mediante la definición de estos dos alias conseguimos que cuando el módulo rss solicite internamente un recurso a: http://localhost:8080/rss realmente acceda a los recurso de la carpeta /export/ccaa/<sitio>/uploads/rss. Análogamente sucede para el alias de la galería de imágenes. Redirección tráfico 8080 En el caso en el cual tanto Apache como JBoss se encuentren en máquinas diferentes, será necesario que todo el tráfico de salida del JBoss con destino la misma máquina (localhost) puerto 80 sea redirigido al puerto 8080. Para ello, deberemos aplicar una regla de iptables (kernel 2.4 o superior) o ipchains (kernel 2.2). En la mayor parte de los sistemas Linux la forma de proceder es la siguiente:

1. Con el usuario root, ejecutamos: iptables -t nat -A OUTPUT -p tcp --destination 127.0.0.1/32 --dport 80 -j DNAT --to-destination 127.0.0.1:8080

2. Comprobamos su correcta ejecución con el comando: iptables -L -n -v

-t nat 3. Si deseamos que la configuración permanezca residente en el próximo

arranque, podemos ejecutar iptables-save > /etc/sysconfig/iptables y comprobar que se arrancará en el runlevel consultando /etc/rc.d/rc3.d/SXXiptables (en el caso de runlevel 3).

2.2.4. Librerías del JBoss JBoss tiene dos directorios de librerías, a conocer:

• $JBOSS_HOME\lib En el directorio lib contiene los JARs necesario para el set up del arranque del JBoss. Dentro del directorio se encuentra un subdirectorio denominado endorsed en el cual, durante la instalación se sobrescribieron los siguientes ficheros:

o resolver.jar o serializer.jar o xalan.jar o xercesImpl.jar o xml-apis.jar

• $JBOSS_HOME\server\default\delpoy\lib

Todos los ficheros JAR del directorio se cargarán por JBoss en el classpath compartido por todos los módulos (WARs). En concreto, agregaremos dos jars comunes a todos los módulos: • mysql-connector-java-5.0.4-bin.jar (para las conexiones con MySQL) • casclient-2.1.1-nossl.jar (autenticación por HTTP) o casclient-2.1.1.jar

(si tenemos certificado y atenticamos por HTTPs)

http://localhost:8080/rss

68

2.2.5. Directorio $JBOSS_HOME/informes El directorio informes del JBoss almacena en su interior los siguientes directorios:

1. birt-runtime-2_2_1_1 Para la generación de informes online la plataforma hace uso de Birt. Los binarios del sistema de reportes Birt se almacenan ahí.

2. destinoInformesDir

Los informes planificados desde el planificador se almacenarán en esta carpeta.

3. plantillasInformes Las plantillas a partir de las cuales Birt genera los informes se encuentran en esta carpeta.

Para la correcta generación de las imágenes de algunos informes es necesario añadir a la máquina virtual de Java (en el script de arranque del JBoss) el parámetro:-Djava.awt.headless=true 2.2.6. Directorio $JBOSS_HOME/indices En el directorio se almacenan los índices generados por Lucene para los diferentes idiomas, existiendo un índice por cada idioma en los que se encuentra disponible la plataforma. Apache Lucene es un motor de búsquedas de alto rendimiento escrito íntegramente en Java que nos permite realizar búsquedas completas por diferentes criterios textuales. Al encontrarse la aplicación disponible en 6 idiomas aparecen 6 índices (subdirectorios dentro de $JBOSS_HOME/indices):

Idioma Subdirectorio índices Catalán ca_CA_simple.id Inglés en_EN_simple.id

Español es_ES_simple.id Euskera eu_EU_simple.id Gallego gl_GL_simple.id

Valenciano va_VA_simple.id Durante los procesos de backup y mantenimiento de la plataforma será de vital importancia hacer un backup de los índices. 2.2.7. Directorio $JBOSS_HOME/uploads El directorio de uploads es el directorio donde se almacenarán los ficheros necesarios para la plataforma (esquemas para las validaciones, plantillas, rss, etc.) y los ficheros que se irán generando a medida que se use la plataforma (descargas disponibles, repositorio con los ODEs cargados, resultados de la elaboración de algunos informes, directorio de taller para la creación de ODEs por parte de los usuarios del portal, etc.).

69

El tamaño de este directorio será elevado y variará en función de:

• Los ODEs creados en el taller. • Los ODEs publicados (tamaño y número) en el repositorio. • Las descargas disponibles desde la plataforma.

El directorio, en general, no será local a la máquina de JBoss, sino que el espacio a usar será accedido remotamente vía NFS, siendo gestionado por un servidor diferente capaz de asignar o desasignar capacidad al mismo dinámicamente mediante un LVM o similar. La estructura de subdirectorios que se presenta en el directorio uploads es la siguiente: descargas galeriaimg/common (contiene los iconos de las imágenes por defecto) galeriaimg/<sitio> (se generarán las previsualizaciones de los ODEs) html (con contenido inicial) imagenesInformes informesPortada modificador noticias repositorio rss schemas (con contenido inicial) schemasImscp (con contenido inicial) schemasScorm12 (con contenido inicial) schemasVdex (con contenido inicial) searchPlugin (con contenido inicial) sitemaps/backup sitemaps/estatico (con contenido inicial) taller utilidades (con contenido inicial) xmls (con contenido inicial) xslt (con contenido inicial) descargas Se albergan todas las descargas disponibles desde el portal Agrega. galeriaimg En el subdirectorio common se encuentran los iconos de las imágenes por defecto (por ejemplo, el thumbnail (mini captura) para los recursos mp3, doc, pdf… En el subdirectorio <sitio> (el nombre de la CCAA) se almacenan todas las capturas de los recursos (ODEs) tomadas por la plataforma durante el proceso de carga. html Almacena ciertos contenidos html estáticos, imágenes, css… imagenesInformes Todas las imágenes de los informes que se generen se guardarán en esta carpeta. informesPortada Los informes accesibles desde la portada (páginas html) se salvarán en esta ruta. modificador

70

El modificador es un módulo que permite cambiar masivamente ODEs del portal. Por cada tarea modificación que realicemos, almacenará la configuración de la modificación y los logs de las modificaciones realizadas. noticias Si las noticias que se suben contienen imágenes, éstas se subirán a este directorio. repositorio Este directorio junto con el taller serán los que generalmente más espacio en disco ocuparán. En el se encuentran todos los ODEs publicados en el portal Agrega descomprimidos. rss Los rss generados por la plataforma permanecerán en éste directorio (ficheros XML) schemas, schemasImscp, schemasScorm12, schemasVdex Contienen diferentes esquemas necesarios para las validaciones y empaquetados de los recursos en los formatos Scorm 2004, Scorm 1.2 e IMS-CP. searchPlugin En el directorio tenemos el fichero searchPlugin.xml, que permite instalar un buscador de Agrega en nuestra barra de buscadores del navegador. El contenido del XML es el siguiente: <?xml version="1.0" encoding="UTF-8"?> <OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/"> <ShortName>Agrega-<sitio></ShortName> <Description>Busqueda en Agrega</Description> … <InputEncoding>UTF-8</InputEncoding> <Url type="text/html" template="http://<sitio>.agrega.indra.es/buscador/ListarODECU/ListarODECU.do? buscadorGeneral={searchTerms}&tipoBusqueda=01"/> </OpenSearchDescription> Los parámetros a tener en cuenta en cada CCAA son el nombre corto y la URL a la que se atacará para realizar la búsqueda. sitemaps En el directorio de sitempas/estatico/ se almacenan los ficheros robots.txt y sitemapPortada.xml. El fichero robots.txt define las políticas de permitir el acceso o denegarlo a los robots que se conecten a la página de agrega. El segundo fichero, sitemapPortada.xml, define las principales URLs del portal para permitir que los robots buscadores conozcan mejor el portal agrega para indexar los contenidos del mismo. Es importante que la URL a la que apunta la tag <loc> sea correcta. <?xml version='1.0' encoding='UTF-8'?> <urlset xmlns="http://www.google.com/schemas/sitemap/0.84" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.google.com/schemas/sitemap/0.84

71

http://www.google.com/schemas/sitemap/0.84/sitemap.xsd"> <url> <loc>http://<sitio>.agrega.indra.es/visualizadorcontenidos/Portada/Portada.do</loc> <lastmod>2008-05-19</lastmod> <changefreq>weekly</changefreq> <priority>0.5</priority> </url> … En el directorio uploads/sitemaps/ la plataforma irá generando los ficheros sitemaps para la portada (sitemapPortada.xml) y para todos los recursos publicados (sitemap1.xml, sitemap2.xml…). Para que cualquier buscador encuentre todos los sitemaps publicados se generará también un fichero llamado sitemap-index.xml que contendrá una referencia a tantos sitemaps como sean necesarios. taller Por cada usuario existirá una carpeta (que será la carpeta personal del portal). Cada usuario podrá crear, catalogar y empaquetar tantos ODEs como desee (en futuras actualizaciones de Agrega existirá el concepto de cuota). Para que un recurso ODE pueda ser publicado, previamente ha de ser creado, catalogado y propuesto para publicación. Hasta que no se publique, el ODE permanecerá en la carpeta personal. Al contener la carpeta taller todos los recursos pendientes de ser publicados, el tamaño total de la carpeta variará en función del número y tamaño de los ODEs que alberga en su interior. utilidades Contiene diverso contenido web:

• AgregaSlider (código flash para hacer referencia a Agrega desde otros sitios)

• ContenidoDinámico: imagen que se genera dinámicamente por la plataforma (selección de una captura de un ODE aleatoriamente)

xmls Conjunto de ficheros XML que definen las taxonomías, tesauros, árbol curricular y vocabularios.

xslt Plantillas para convertir a los formatos SCORM 1.2 e IMS-CP. 2.2.8. Ficheros de configuración del portal Agrega En el directorio $JBOSS_HOME/server/default/conf encontramos los archivos de configuración del JBoss y del portal Agrega. En concreto, los ficheros de configuración de Agrega son: agrega.properties authbackend.properties cas.properties dependentServer_EN.properties dependentServer.properties

72

generacionContenidos.properties i18n_ca.properties i18n_en.properties i18n_es.properties i18n_eu.properties i18n_gl.properties i18n.properties i18n_va.properties importedServices.properties log4j.xml springldap.xml agrega.properties El contenido más relevante del fichero es el que se muestra a continuación, hemos dividido en partes la estructura del mismo para intercalar las explicaciones: ########## Variables de configuracion del correo ########## hostSmtp=servidor_correo debug=true #Direccion de correo del sistema, se utilizara como from en el servicio Recuerdo Clave fromSender=usuario@dominio ldapExternal=false ########## Correo del administrador del servidor ldap externo ###### adminLdapExternal=administrador_ldap@dominio ########## Autenticacion de correo #### autentication=true userSmtp=usuario passwordSmtp=password Configuramos el servidor de correo, especificando el hostSmtp, el formSender que se utiliza como campo from, el userSmtp y passwordSmtp empleados para el envío de mensajes (si la authentication está puesta a true). Con respecto al LDAP, podemos configurar:

• ldapExternal=true Si especificamos la variable a true, indicamos que el LDAP será de solo lectura (no escritura), por lo que, cada vez que un usuario se de de alta en el portal, se enviará un mail automáticamente al administrador del LDAP (adminLdapExternal) solicitándole que realice el alta manual en el LDAP.

• ldapExternal=false En caso de especificar el valor a false, cada vez que se crea, borra o modifica un usuario del portal Agrega, los cambios se verán reflejados automáticamente en el LDAP.

########## Idioma idioma.selected=es zona_horaria=CEST ########## Usuario administrador que no podra ser eliminado ############# rol_administrador=ADMINISTRADOR Especificamos el idioma seleccionado por defecto, la zona horaria y el nombre del rol administrador.

73

########## Ip del servicio de auditoria auditoria.host=localhost auditoria.puerto=8080 ########## Ip del servicio de administración de usuarios admin.ws.host=localhost admin.ws.puerto=8080 path_logs=/opt/jboss/server/default/log logs_no_borrar=server.log,agrega.log,boot.log # Parametro que indica si queremos o no queremos auditoria auditoria=SI Se especifican el host y el puerto de los webservices de auditoría y administración de usuarios. Además, se define el directorio donde se encontrarán los logs (para ser mostrados desde el módulo de la aplicación) así como si se desea o no habilitar la auditoría. ######################################################## ###### Configuración para los informes ###### ######################################################## #Librerías de Birt birtDir=informes/birt-runtime-2_2_1_1/ReportEngine/ #Plantillas de los informes informesDir=informes/plantillasInformes/ #Directorio donde se guardarán todos los informes destinoInformesDir=informes/destinoInformesDir/ #Directorio donde se copiaran las imagenes de los diagramas imgBirtDir=uploads/imagenesInformes/ #path del servidor que enlazara al directorio de las imagenes staticImgDir=/imagenesInformes/ #Path de los informes 'Mas' de la portada pathInformesPortada=informesPortada/ ##### Configuración de los informes 'Mas' de la Portada ###### destinoInformesMasDir=uploads/informesPortada/ #Número máximo de elementos que presentará cada tipo de informe rangoInformesPortada=10 #Número de días para los cuales se quiere calcular los informes 'Mas' de la portada diasAnterioresInformesPortada=7 #Primer sufijo que se añadirá al nombre de los informes 'Mas' de la Portada que contienen información de más de un día (relacionado con diasAnterioresInformesPortada) nombreInformesPortadaSemanales=-semanal #Segundo sufijo dias=dias #Nombre de los ficheros que contienen los informes estadoOdes=informeEstadoOdes operacionesRealizadas=informeOperacionesRealizadas nivelAgregacion=informeNivelAgregacion coberturaCurricular=informeCoberturaCurricular terminosBusqueda=informeTerminosBusqueda odesUsuario=informeOdesUsuario odesLicencias=informeOdesLicencias usuarios=informeUsuarios procesosPlanificados=informeProcesosPlanificados masValorado=informeODEmasValorado masMostrado=informeODEmasMostrado masPrevisualizado=informeODEmasPrevisualizado masDescargado=informeODEmasDescargado

74

tamanio=informeODEmasGrandes #Nombre del informe con el catálogo de Agrega informeCatalogo=CatalogoAgrega Diversos parámetros para la configuración de los informes generados por el runtime de Birt. La mayor parte de los nombres los hace autodescriptivos. ######################################################### ####### Configuración para la galería de imágenes ####### ######################################################### #host o IP de la máquina en la que se encuentra el servico que genera las imagenes galeriaimg.server.ip=localhost:8080 #URL del servicio galeriaimg.service.url=RemotingGalleryServer/remoting/RemotingGalleryService #Inicio de la ruta relativa (alias de apache) donde se encuentran accesibles las imágenes del nodo galeriaimg.path.image=/galeriaimg #Inicio de la ruta relativa (alias de apache) donde se encuentran accesibles las imágenes comunes galeriaimg.common.image=/imgcommon #Extensión de la imagen que se genera galeriaimg.image.ext=.png #Extensiones con icono por defecto galeriaimg.image.common.ext=MP3,WAV,WMA,AIFF,OGG,TAR,RAR,ZIP,TGZ,PPT, PDF,XLS,DOC,PPS #Ruta disco imagenes icono por defecto relativa al path del nodo galeriaimg.image.common.path=uploads/galeriaimg/common # Ruta relativa donde se generan las imagenes # Se usa para chequear si la imagen se ha generado o no path.generatedimgs=uploads/galeriaimg/ # ruta relativa del fichero de generacion imagenes script.html.generatedimgs=./bin/generateimg.sh # ruta relativa del fichero de generacion imagenes script.img.generatedimgs=./bin/resizeimg.sh # Lista de extensiones que no deben abrir el firefox img.resize.extension=gif,jpg,jpeg,jpe,tiff,tif,cmu,pnm,pbm,pgm,ppm,rgb,xbm,xpm,bmp #Lista de rutas a concatenar al localizador #NOTA:Recordar que la ruta del localizador es relativa al servidor #en el que se encuentra <sitio>.path=/export/<sitio> Con respecto a la galería de imágenes, primero configuramos la IP, puerto y URL donde atacar el servicio (normalmente localhost:8080, RemotingGalleryServer/remoting/RemotingGalleryService). Posteriormente se especifican diversos parámetros, tales como todos los paths donde encontrar los iconos por defecto, las imágenes generadas, listas de ficheros de extensiones que mostrarán un icono por defecto… Los binarios generateimg.sh y resizeimg.sh que capturan las imágenes se verán en detalle en la sección de la galería de imágenes. ###############################

75

####### Catalogos Agrega ####### ############################### catalogo.agrega=Plataforma Agrega catalogo.mec=Catálogo unificado mec-red.es-ccaa de identificación de ODE Nombres especificados en los catálogos. ################################# ######Configuración RSS########## ################################# rss=/rss host=url_host rss.path=uploads/rss/ El modulo de RSS hace uso de 3 propiedades, la que dependerá en cada CCAA será la propiedad host. ####################################### ###Configuración Plugin de búsqueda#### ####################################### searchPlugin=/searchPlugin Alias de apache donde se encontrará el fichero del searchPlugin.xml ####################################### #####Identificador único de nodo####### ####################################### idNodo=NODO20080422102550 Cada nodo debe poseer un identificador único que se asigna en la instalación. ####################################### ########Flag para nodo neutro########## ####################################### neutro=false En las comunidades este flag deberá estar siempre a false, controla las plantillas y opciones del portal. ################################### ########## Generacion Dinamica##### ################################### #URL de la imagen dinamica urlImagenDefecto=utilidades/contenidoDinamico/imagenPorDefecto.jpg urlImagenDefectoGrande=utilidades/imagenPorDefectoGrande.jpg urlImagenDinamicaDisco=utilidades/contenidoDinamico/imagenDinamica.png pathImagenDinamicaDisco=uploads/utilidades/contenidoDinamico/imagenDinamica.png pathImagenDefectoGrande=uploads/utilidades/imagenPorDefectoGrande.jpg Para la generación dinámica de las imágenes del portal se hace uso de las propiedades anteriores, simplemente especifican los directorios donde encontrar las imágenes por defecto y los directorios donde se almacenarán las capturas aleatorias elegidas.

76

######## Correo de registro del cas ############################ # Correo del usuario que se encargará de dar de alta a los usuarios correoCas=usuario@domino Cuando un usuario desee darse de alta en el portal, deberá enviar un correo a la dirección que aparece en la ventana de acceso al portal. En cada CCAA apuntará al administrador de los usuarios del mismo. ######### Tiempo extendido de sesion para empaquetador (segundos ) ############# timeout.extendido=86400 Tiemout definido especialmente para el empaquetador (en segundos). Se debe a que los tiempos medios de empaquetación suelen ser mucho mayores que los timeouts de sesión. ######### Esquema de metadatos LOM-ES ############################## esquemaDeMetadatos=LOM-ESv1.0 Versión de esquema de metadatos empleada. ######## Atributos de configuracion del servidor oai-pmh ######### urlRepositorio=http://pruebas.agrega.indra.es/oaipmh/OaiPmhRequest/OaiPmhRequest.do nombreRepositorio=Agrega emailAdmin=usuario@domino Propiedades de configuración para el servidor oai-pmh. ########### enlace a changeLog pathChangeLog=/utilidades/changelog.html Directorio donde se ubicará el fichero changelog.html, el cual contiene los cambios entre las diferentes versiones. ############################# ########## Contacto ######### ############################# contacto_mail=usuario@domino contacto_telefono=91 111 22 33 ##########Activar opcion de incidencias de contacto(true-activar,false-desactivar) contacto_incidencias_activar=false Cuando un usuario accede a la página de contacto del portal, se le mostrarán los datos suministrados por estas 3 propiedades: el contacto por mail y por teléfono se visualizarán siempre, mientras que la gestión de incidencias puede ser activada o desactivada. Por defecto para todas las CCAA el campo relacionado con las incidencias estará inicialmente a false, únicamente se marcaría a true si la CCAA habilita un sistema de gestión de incidencias para sus usuarios. ##########Version de la aplicacion version=1.0.3 Número de versión de la aplicación.

77

authbackend.properties Define los parámetros necesarios para la autenticación contra el LDAP por parte del módulo CAS: ibuilder.security.ldap.url=ldap://servidor_ldap:389/dc=pruebas,dc=agrega,dc=indra,dc=es ibuilder.security.ldap.managerDN=cn=Administrador,dc=agrega,dc=indra,dc=es ibuilder.security.ldap.managerPwd=password ibuilder.security.ldap.userSearchBase=ou=usuarios ibuilder.security.ldap.userSearchFilter=(cn={0}) ibuilder.security.ldap.groupRoleAttribute=cn ibuilder.security.ldap.groupSearchBase=ou=roles cas.http.url=http://cas-nodo.agrega.indra.es/cas http.server=http://nodo.agrega.indra.es Se debe proporcionar la url de conexión al servidor LDAP especificando la base DN. También se debe especificar el usuario manager para poder crear, borrar, modificar los usuarios en el LDAP. Por último, el módulo CAS necesita conocer cuál es la URL del cas y la URL del portal. cas.properties El fichero cas.properties únicamente contiene una línea en la que se especifica la URL del nodo: entorno=nodo.agrega.indra.es dependentServer.properties y dependentServer_EN.properties server.on=nodo nodo.server.id=es_nodo_20080422121523455 nodo.ccaa=nombre_largo_nodo Se configura el nombre del nodo asignado al servidor y un identificador único para el servidor. Mediante la clave <nodo>.ccaa podemos especificar el nombre largo del nodo. A continuación vienen unos parámetros configurados de serie con las comunidades: redes.nodo=MEC ute.nodo=MEC cnice.nodo=MEC andalucia.nodo=AN aragon.nodo=AR asturias.nodo=AS baleares.nodo=BA canarias.nodo=IC cantabria.nodo=CB castillalamancha.nodo=CM castillayleon.nodo=CL catalunya.nodo=CT extremadura.nodo=EX galicia.nodo=GA

78

larioja.nodo=LR madrid.nodo=MA murcia.nodo=MU navarra.nodo=NA valencia.nodo=CV ccaas=Junta de Andalucía,Comunidad Autónoma de Aragón,Comunidad del Principado de Asturias,Comunidad Autónoma de Canarias,Comunidad Autónoma de Cantabria, Junta de Castilla la Mancha,Junta de Castilla y Leon,Generalitat de Catalunya,Junta de Extremadura,Xunta de Galicia,Comunidad Autónoma de La Rioja,Comunidad de Madrid,Comunidad Autónoma de Murcia,Comunidad Foral de Navarra,Generalitat Valenciana nodos=MEC,AN,AR,AS,IC,CB,CM,CL,CT,EX,GA,LR,MA,MU,NA,CV urlNodo=http://url_nodo #Usado para Galeria de Imagenes #Lista de rutas a concatenar al localizador #NOTA:Recordar que la ruta del localizador es relativa al servidor #en el que se encuentra redes.path=/export/ccaa/redes madrid.path=/export/ccaa/madrid andalucia.path=/export/ccaa/andalucia aragon.path=/export/ccaa/aragon asturias.path=/export/ccaa/asturias canarias.path=/export/ccaa/canarias cantabria.path=/export/ccaa/cantabria castillayleon.path=/export/ccaa/castillayleon catalunya.path=/export/ccaa/catalunya extremadura.path=/export/ccaa/extremadura galicia.path=/export/ccaa/galicia larioja.path=/export/ccaa/larioja murcia.path=/export/ccaa/murcia navarra.path=/export/ccaa/navarra valencia.path=/export/ccaa/valencia Además de especificar la url del nodo, es necesario especificar la ccca.path que sea al directorio anterior a uploads/galeriaimg para el correcto funcionamiento de la galería de imágenes. El fichero dependentServer_EN.properties es el mismo pero internacionalizado al inglés. generacionContenidos.properties #################################################################### # ATRIBUTOS DE LA TAREA DE GENERACIÓN DEL ODE # DE LA PORTADA #################################################################### #D : diaria, M: mensual, A:anual periocidadOdePortada=H horaTareaOde=1 minutoTareaOde=0 segundoTareaOde=0

79

Definimos con estas propiedades la periodicidad con la que se va a seleccionar un ODE cualesquiera del repositorio, para generarse la captura diaria. periodicidadOdePortada puede valer “M”, “D” y “H” (Mensual, Diaria, Horaria). En el caso de periodicidad Horaria no aplican el resto de propiedades. Si especificamos la periodicidad Diaria es necesario especificar la Hora, Minuto y el Segundo en el cual se lanzará la tarea de generación del ODE. A partir de aquí, el fichero especifica diversas propiedades para la generación de los ficheros Sitemaps (ficheros XML que definen las URL que visita cada bot que nos navega para indexar los contenidos del portal, por ejemplo google-bot). ####################################################################### # ATRIBUTOS DEL FICHERO SITEMAP # ####################################################################### ########### Periodicidad de cambio del repositorio ########################## # Los valores posibles son (always hourly daily weekly monthly yearly never) periodicidad=monthly ########### Nº de entradas (url) que contendrá como máximo cada fichero sitemap.xml ############ # Numero entradas <url> en el fichero sitemap.xml no debe superar las 50.000 urls ni tampoco los 10MB numeroEntradas=3000 ########### Nombre de los ficheros sitemap y sitemapIndex ################## # Nombre de los ficheros sitemap ficheroSiteMap=sitemap # Nombre del fichero sitemapindex ficheroSiteMapIndex=sitemap-index ########### Extensión de los ficheros sitemap y sitemapIndex ############### extensionFicheroSiteMap=xml Especificamos que el número de entradas por fichero sea de 3000, la periodicidad de actualización será mensual y el fichero índice que contiene todos los ficheros sitemaps se denomina sitemap-index.html. ########### Schema sitemap y sitemapIndex #################### schemaSitemap=http://www.google.com/schemas/sitemap/0.84 schemaSitemapXsi=http://www.w3.org/2001/XMLSchema-instance schemaSitemapLocation=http://www.google.com/schemas/sitemap/0.84 http://www.google.com/schemas/sitemap/0.84/sitemap.xsd schemaSitemapIndex=http://www.sitemaps.org/schemas/sitemap/0.9 schemaSitemapIndexXsi=http://www.w3.org/2001/XMLSchema-instance schemaSitemapIndexLocation=http://www.sitemaps.org/schemas/sitemap/0.9 http://www.sitemaps.org/schemas/sitemap/0.9/siteindex.xsd Diversos schemas necesarios para la generación de los sitemaps. ########### Directorios de los ficheros sitemap y sitemapIndex ################

80

# Url donde se dejarán los ficheros sitemap.xml. Deberá almacenarse en un directorio de tal manera que # la url de acceso sea http://tudominio/sitemap.xml urlSiteMap=uploads/sitemaps/ # Url donde se dejarán los ficheros backup de los ficheros sitemap urlSiteMapBackup=uploads/sitemaps/backup/ # Url donde se dejará el fichero sitemap con las url de la portada urlSiteMapPortada=uploads/sitemaps/estatico/ Directorios donde se almacenarán los ficheros sitemaps y el sitemap-index. Además, cuando se generan los nuevos sitemaps se mueven los anteriores al directorio backup especificado. ############### Url de la ficha de los odes ######## # Protocolo de las fichas de los odes protocoloHttp=http:// # Url de la ficha del ode buscadorFicha=/ODE/ # Carácter separador de la url (el formato de la url de la ficha será con urls cortas: http://dominio/ODE/idioma/idOde) separador=/ Diversos parámetros necesarios para generar la URL que acceda a la ficha de los ODEs. ############### Prioridad asociada al nivel de agregación ################ # nivel_agregacion_ode=prioridad 1=0.2 2=0.4 3=0.7 4=1 Los ODEs de la plataforma tienen asociado un nivel de agregación (complejidad del objeto, a mayor nivel mayor complejidad). Existen 4 niveles de agregación, las propiedades nos permiten configurar los pesos asociados a los objetos en función de su nivel de agregación cuando se escriban las preferencias en el fichero sitemap. ############## Variables de configuracion de la tarea programada de generación de sitemap.xml ###### #D : diaria, M: mensual, A:anual periodicidadTarea=D horaTarea=1 minutoTarea=0 segundoTarea=0 Por ultimo, se define la periodicidad de la generación de los ficheros sitemaps. El comportamiento es el mismo i18n_ca.properties, i18n_en.properties, i18n_es.properties, i18n_eu.properties, i18n_gl.properties, i18n.properties,

81

i18n_va.properties El fichero i18n.properties contiene los idiomas en los que podrán realizar las búsquedas, el idioma por defecto del portal y el idioma secundario: # Lista de idiomas buscables de la plataforma. idiomas.buscables=es,ca,en,eu,gl,va # Lista de idiomas en los que se puede mostrar la plataforma idiomas.plataforma=es,ca,en,eu,gl,va # Idioma por defecto en el que se muestra la plataforma idioma.por.defecto=es # Idiomas traducibles: todos los idiomas para los que tenemos traduccion. En cada bundle # tendra que estar cada idioma de esta lista traducido idiomas.traducibles=es,ca,en,eu,gl,va idioma.secundario= Cada fichero i18n_XX.properties contiene los nombres de los idiomas internacionalizados. Por ejemplo, el fichero i18n_en.properties: #Idiomas por parejas ISO=Nombre Idioma y Nombre Idioma=ISO es=spanish spanish=es ca=catalan catalan=ca en=english english=en eu=basque basque=eu gl=galician galician=gl va=valencian valencian=va importedServices.properties Si algún servicio no se despliega en la misma máquina, será necesario especificar la URL donde se publica el servicio remoto en el fichero. Por defecto, al encontrarse todos los servicios desplegados en el mismo servidor de aplicaciones el fichero tendrá todas las propiedades vacías como se muestra a continuación: srvAdminUsuariosServicePort= srvAgregadorRssServicePort= srvAuditaPublicacionServicePort= srvAuditoriaServicioPort= srvAuditoriaValoracionServicePort= srvAuditoriaIndexadorServicePort= srvBuscarFederadaServicePort= srvBuscadorServicePort= srvBuscarServicePort= srvCatalogacionBasicaServicePort= srvCatalogacionAvanzadaServicePort=

82

srvDescargasPort= srvEmpaquetadorBasicoServicePort= srvEntregarServicePort= srvEstructurasEducativasServicePort= srvFachadaAgregarServicePort= srvFaqServicePort= srvGeneracionDinamicaServicePort= srvGestorArchivosServicePort= srvGestorManifestServicePort= srvHerramientaModificacionPort= srvIndexadorServicePort= srvInformeServicePort= srvLocalizadorServicePort= srvLogServicePort= srvMonitorizarServicePort= srvNodoServicePort= srvNoticiasServicePort= srvPlanificadorServicePort= srvPublicacionServicePort= srvRegistroPlanificadorServicePort= srvSitemapServicePort= srvTaxonomiaServicePort= srvTesaurosServicesPort= srvValidadorServicePort= srvValidadorVDEXServicePort= srvValoracionServicePort= srvVocabulariosControladosServicePort= log4j.xml Para generar los logs el portal hace uso de Log4j. En el fichero de configuración ubicado en $JBOSS_HOME/server/default/conf/log4j.xml definimos los siguientes “appenders”: FILE, ServiceErrors y agrega. <appender name="FILE" class="org.jboss.logging.appender.DailyRollingFileAppender"> <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/> <param name="File" value="${jboss.server.log.dir}/server.log"/> <param name="Append" value="true"/>  <param name="DatePattern" value="'.'yyyy-MM-dd"/>  <layout class="org.apache.log4j.PatternLayout">  <param name="ConversionPattern" value="%d %-5p [%c] %m%n"/>  </layout> </appender> <appender name="ServiceErrors"

83

class="org.jboss.logging.appender.DailyRollingFileAppender"> <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/> <param name="File" value="${jboss.server.log.dir}/service-error.log"/> <param name="Append" value="true"/>  <param name="DatePattern" value="'.'yyyy-MM-dd"/>  <layout class="org.apache.log4j.PatternLayout">  <param name="ConversionPattern" value="%d %-5p [%c] %m%n"/>  </layout> </appender> <appender name="agrega" class="org.jboss.logging.appender.DailyRollingFileAppender"> <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/> <param name="File" value="${jboss.server.log.dir}/agrega.log"/> <param name="Append" value="true"/>  <param name="DatePattern" value="'.'yyyy-MM-dd"/>  <layout class="org.apache.log4j.PatternLayout">  <param name="ConversionPattern" value="%d %-5p [%c] %m%n"/>  </layout> </appender> Se ha especificado que los logs se almacenen en el directorio ${jboss.server.log.dir}/fichero.log, que se corresponde con el directorio $JBOSS_HOME/server/default/log. En la configuración de los “appenders”, se ha hecho uso de la clase org.jboss.logging.appender.DailyRollingFileAppender para que roten diariamente con los patrones que aparecen en el fichero de configuración. Los niveles de verbosidad y paquetes se configuran en las secciones siguientes: <category name="org.springframework"> <priority value="INFO"/> </category> <category name="ServiceErrorsLogger">

84

<priority value="ERROR" /> <appender-ref ref="ServiceErrors"/> </category> <category name="es.pode"> <priority value="INFO"/> <appender-ref ref="agrega"/> </category> <category name="es.agrega"> <priority value="INFO"/> <appender-ref ref="agrega"/> </category> En las categorías especificamos el paquete Java, la prioridad a mostrar (DEBUG, INFO, WARN, ERROR, FATAL) y podemos especificar uno o más appenders en los que se escribirán los logs de las clases pertenecientes al paquete. Todos los loggers heredan de la categoría raíz, definida de la siguiente manera: <root> <priority value="INFO"/> <appender-ref ref="CONSOLE"/> <appender-ref ref="FILE"/> </root> Si queremos cambiar la prioridad de todas las clases por defecto a INFO, es importante introducir la línea “<priority value ="info" />” dentro de la sección root previa. Los valores almacenados en las categorías citadas anteriormente prevalecen sobrescribiendo los valores de la categoría root. springldap.xml En el fichero de configuración springldap.xml definimos la conexión al LDAP por parte de los módulos del portal para autenticarse. El contenido, deberá reflejar la estructura del LDAP de cada CCAA, a modo de ejemplo mostramos el fichero plantilla usado: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd"> <beans> <bean id="contextSource" class="org.springframework.ldap.support.LdapContextSource"> <property name="url" value="ldap://ldapserver:389/ou=usuarios,dc=<nodo>,dc=agrega,dc=indra,dc=es" /> <property name="userName" value="cn=Administrador,dc=agrega,dc=indra,dc=es" /> <property name="password" value="contraseña"/> </bean> <bean id="ldapTemplate" class="org.springframework.ldap.LdapTemplate"> <constructor-arg ref="contextSource" /> </bean> <bean id="ldapContact" class="es.pode.adminusuarios.negocio.comun.LDAPContactDAO">

85

<property name="ldapTemplate" ref="ldapTemplate" /> </bean> </beans> Las líneas resaltadas son:

• url: Especificamos la URL de conexión al LDAP en donde se buscarán los usuarios. Se ha especificado la base a partir de la cual se realizarán todas las operaciones del LDAP.

• userName: usuario que sera usado para obtener el contexto autenticado. Corresponde con el DN del usuario Administrador.

• password: contraseña del usuario administrador. 2.2.9. Despliegue del aplicativo: WARs Tanto los servicios como los módulos web se deben desplegar en el directorio $JBOSS_HOME/server/default/deploy/agrega/ Los wars correspondientes a la versión 1.0.3 son: 1 adminusuarios-1.0.war 2 agregadorRSS-1.0.war 3 auditoria-1.0.war 4 buscador-1.war 5 buscar-1.war 6 cas.war 7 catalogacion-1.war 8 catalogadorWeb-1.war 9 contenidosportal-F1.war 10 dri-1.war 11 empaquetadorbasico-F1.war 12 entregar-1.war 13 fuentestaxonomicas-1.war 14 gestorflujo-1.war 15 indexador-0.1.war 16 localizador-1.war 17 modificador-1.war 18 ModificadorWeb-1.war 19 oaipmh-1.0.war 20 planificador-1.0.war 21 portaladministracion-F1.war 22 PortalEmpaquetador-F1.war 23 publicacion-1.war 24 RemotingGalleryServer.war 25 reputacion-1.war 26 validador-1.war 27 valoracion-1.war 28 visualizador-1.war 29 visualizadorcontenidos-F1.war Una vez arrancado el JBossAS, los JSPs compilados (servlets generados) se encontrarán disponibles en el directorio: $JBOSS_HOME/server/default/work/jboss.web/localhost El contenido de clases, librerías, ficheros XML de configuración… de los WARs se

86

desplegará en el directorio: $JBOSS_HOME/server/default/tmp/deploy Cada vez que se quiera desplegar un módulo, sobrescribiendo uno actual, podemos realizar la tarea de dos maneras:

1. Copiamos el WAR en caliente (hot deploy): sin parar el servidor de aplicaciones JBoss, después de haber realizado un backup del war, copiamos el nuevo sobre el viejo, produciéndose las tareas de undeploy y dedeploy del módulo. JBoss escanea el directorio de los wars para detectar los cambios cada cierto tiempo, la configuración del scanner se encuentra en $JBOSS_HOME/server/default/conf/jboss-service.xml

<mbean code="org.jboss.deployment.scanner.URLDeploymentScanner" name="jboss.deployment:type=DeploymentScanner,flavor=URL">  <depends optional-attribute-name="Deployer">jboss.system:service=MainDeployer</depends> … …  <attribute name="ScanPeriod">60000</attribute>  <attribute name="ScanEnabled">true</attribute> Se define mediante la propiedad ScanEnabled si está o no habilitado el mbean de JBoss, y mediante la propiedad de ScanPeriod definimos en milisegundos el tiempo entre comprobaciones de nuevos wars o modificaciones de los existentes.

2. Copiamos el WAR habiendo parado el JBoss: una vez detenido el servicio del JBoss, procedemos a sobrescribir el WAR, borrar los directorios temporales citados anteriormente y arrancamos de nuevo el servicio. Es el método más limpio y recomendado para las actualizaciones de la plataforma.

2.3. Galería de imágenes La galería de imágenes se invoca desde el módulo publicador a través del protocolo RMI tal y como se muestra en la siguiente figura:

87

¡BOOM!

Publicación

RemotingGalleryServer

RMI

COLA JMS

$fileType == "image" $fileType == "video"

else

convert Firefox+

import

ffmpeg

El publicador, por cada elemento publicado, inserta un mensaje en una cola JMS. Asíncronamente un listener va consumiendo los mensajes de la cola JMS y vía RMI invoca al módulo de la galería de imágenes. En el mensaje RMI se intercambia la siguiente información:

• URL del fichero del recurso (en disco) a capturar. • Directorio donde almacenar la captura • Nombre del fichero donde se guardará la captura.

La galería de imágenes, una vez que ha recibido la información del recurso del ODE a capturar, el directorio y fichero a generar, invoca una shell del sistema ejecutando el fichero generateimg.sh o resizeimg.sh (disponibles en el directorio $JBOSS_HOME/bin). El función del tipo de contenido los scripts capturarán la imagen de una u otra manera. Tanto los directorios como los scripts a invocar son configurables en el fichero agrega.properties. 2.3.1. Scripts ejecutados Existen dos scripts que pueden ser ejecutados. Si la aplicación de antemano conoce que el recurso es una imagen, invocará directamente al script resizeimg.sh. En caso contrario, se ejecuta el script generateimg.sh. resizeimg.sh El contenido del script resizeimg.sh es el siguiente: #!/bin/bash

88

# constantes UPLOADS_PATH=uploads/galeriaimg; IMAGE_FINAL_SIZE=100x100; echo "Parametros = [$1] [$2] [$3]" if test -z $1 then echo "Falta el primer parametro obligatorio de la llamada" exit fi if test -z $2 then echo "Falta el segundo parametro obligatorio de la llamada" exit fi if test -z $3 then echo "Falta el tercer parametro obligatorio de la llamada" exit fi mkdir -p $UPLOADS_PATH/$3/$1/ #echo "Copio el fichero [$2] en [$UPLOADS_PATH/$3/$1/]" #cp $2 $UPLOADS_PATH/$3/$1/ echo "Convirtiendo la imagen $2 al formato JPG en $UPLOADS_PATH/$3/$1/$1_captured.jpg ..." `date` convert -resize 800x600 "$2" $UPLOADS_PATH/$3/$1/$1_captured.jpg echo "[OK] Imagen convertida correctamente" `date` echo "Generando imagen reducida $UPLOADS_PATH/$3/$1/$1.png ..." `date` convert -resize $IMAGE_FINAL_SIZE $UPLOADS_PATH/$3/$1/$1_captured.jpg $UPLOADS_PATH/$3/$1/$1.png echo "[OK] Imagen reducida generada correctamente" `date` El script, habiendo recibido los 3 parámetros necesarios, ejecuta el comando convert (de ImageMagick) redimensionando la imagen primero a 800x600 y luego a 100x100. De esta forma, se generan 2 imágenes, una grande y otra pequeña (la que se muestra en la ficha). generateimg.sh Cuando no se conoce de antemano el formato del recurso a capturar, se invoca este script. El contenido del mismo es: #!/bin/bash # constantes videoDelayCaptureInSeconds=3; UPLOADS_PATH=uploads/galeriaimg; IMAGE_FINAL_SIZE=100x100; echo "Parametros = [$1] [$2] [$3]"

89

if test -z $1 then echo "Falta el primer parametro obligatorio de la llamada" exit fi if test -z $2 then echo "Falta el segundo parametro obligatorio de la llamada" exit fi if test -z $3 then echo "Falta el tercer parametro obligatorio de la llamada" exit fi mkdir -p $UPLOADS_PATH/$3/$1/ fileType=`file -bi "$2" | awk -F'/' '{print $1}'` echo "FileType is: '$fileType'" if [ $fileType == "image" ] then echo "Convirtiendo la imagen $2 al formato JPG en $UPLOADS_PATH/$3/$1/$1_captured.jpg ..." `date` convert "$2" $UPLOADS_PATH/$3/$1/$1_captured.jpg echo "[OK] Imagen convertida correctamente" `date` elif [ $fileType == "video" ] then echo "Capturando del video a los $videoDelayCaptureInSeconds segundos a una imagen JPG..." `date` ffmpeg -i "$2" -y -ss $videoDelayCaptureInSeconds -t 0.01 -f mjpeg $UPLOADS_PATH/$3/$1/$1_captured.jpg echo "[OK] Video capturado correctamente" `date` else echo "Capturando el fichero $2 desde un navegador..." `date` Xvfb :1 -fp /usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/ fonts/75dpi/ -screen 0 1280x800x24 & DISPLAY=:1 /opt/firefox/firefox -no-remote -height 800 -width 1280 file:"$2" & sleep 5 DISPLAY=:1 import -window root $UPLOADS_PATH/$3/$1/$1_captured.jpg killall firefox-bin killall firefox killall run-mozilla killall run-mozilla.sh killall Xvfb echo "[OK] Ventana de navegador capturada correctamente" `date` fi echo "Generando imagen reducida $UPLOADS_PATH/$3/$1/$1.png ..." `date` convert -resize $IMAGE_FINAL_SIZE $UPLOADS_PATH/$3/$1/$1_captured.jpg $UPLOADS_PATH/$3/$1/$1.png echo "[OK] Imagen reducida generada correctamente" `date` Con ayuda del comando file y awk obtenemos el tipo de recurso que deseamos

90

capturar. En principio, el script analiza 3 posibilidades (tal y como se refleja en la figura inicial):

1. fileType=image Si el tipo de fichero es imagen, capturamos la misma redimensionándola primero a 800x600 mediante el comando convert de ImageMagick.

2. fileType=video

Si el tipo de fichero es un video, hacemos uso del programa FFmpeg capturando el segundo especificado por la propiedad videoDelayCaptureInSeconds (por defecto 3 segundos).

3. Cualquier otro caso

Si el tipo de fichero no es ni imagen ni video, la única forma para generar una captura de pantalla consiste en abrir un navegador web con diversos plugins instalados (firefox en fullscreen) y tomar una captura de pantalla del mismo firefox. Para ello, hacemos uso de: firefox y un sistema de frame buffer virtual Xvfb.

Por último, capturada la imagen grande la redimensionamos a 100x100 para generar la imagen pequeña (la que aparece junto a la ficha del recurso). 2.3.2. Software requerido El software necesario para que funcionen los scripts anteriores es:

• awk • Xvfb • ImageMagick • FFmpeg • Xfonts-100dpi • Xfonts-75dpi • Xfonts-base • Plugin de flash para el mozilla-firefox

Durante la instalación de Firefox, se habrán seguido los siguientes pasos:

• Descarga de firefox de la propia Web de mozilla-firefox y descompresión en el directorio /opt/firefox. wget http://download.mozilla.org/?product=firefox-2.0.0.14&os=linux&lang=es-ES

• Descarga del plugin de Adobe flash player. • Creamos el enlace simbólico al plugin de flash (ejemplo, particularizar con

las rutas reales): ln-s /usr/lib/mozilla/plugins/libflashplayer.so libflashplayer.so

• Con el usuario que arranque JBoss, escribimos en su home el directorio “.mozilla”, que contiene toda la configuración de firefox ya establecida (se facilita el fichero firefoxConf.tar).

• Modificamos el fichero extensions.ini en la línea “Extension2” para que apunte al path correcto donde se encuentra el home del usuario jboss y los archivos que hemos desplegado. cd ~/.mozilla/firefox/a6czhy0t.default/ Editamos la línea:

http://download.mozilla.org/?product=firefox-2.0.0.14&os=linux&lang=es-ES

Extension2=/opt/jboss/.mozilla/firefox/a6czhy0t.default/

91

extensions/{bfe3406c-6f31-4789-86d5-efa50e12c9eb} Los plugins instalados y configurados en firefox son:

• Adobe flash plugin (Shockwave Flash) • Plugin fullscreen (full_fullscreen-2.0-fx.xpi)


2 h


3. Capa de servidor web En la capa del servicio web podemos distinguir al menos 3 componentes fundamentales:

• Servidor web: con el fin de atender todas las peticiones y los componentes estáticos tales como imágenes, CSS, JS, disponemos de un servidor web Apache 2.X instalado.

• Ayuda Mediawiki: la ayuda se basa en el popular software libre Mediawiki. Se trata de una aplicación PHP disjunta del portal instalada directamente sobre Apache.

• Proxy cache: para aquellos contenidos que sean susceptibles de ser almacenados en caché tales como imágenes, CSS, JS, e incluso algunos contenidos (ODEs) solicitados muy a menudo, se propone el uso de un Proxy cache como Squid. Otras opciones como habilitar el módulo de caché de Apache o la caché cualquier otro servidor web serían totalmente válidas.

3.1. Apache 2 Dada la naturaleza de software libre y el presente uso en la mayoría de las CCAA, se ha escogido Apache 2.x como servidor web. Durante la instalación, en caso de no existir un Apache previo, se habrá instalado la última versión estable de Apache 2.0.X (siendo a fecha de la escritura del manual la versión 2.0.63 la última versión estable). En caso de existir ya instalado un servidor web Apache, simplemente se seguirán las guías de configuración recomendadas por JBoss y se creará el virtual host necesario. Con respecto a las conexiones, recordamos que los usuarios se conectarán desde Internet al Apache (puerto 80 y puerto 443 para HTTPS). El servidor HTTPd establecerá conexiones mediante el conector AJP con el servidor de aplicaciones JBoss (puerto 8009), y también abrirá conexiones a la base de datos para la MediaWiki. Gráficamente podemos verlas en la siguiente figura:

92

3.1.1. Módulos Apache necesarios La configuración del vhost va a hacer uso de al menos los siguientes módulos de Apache:

• modules/mod_alias.so • modules/mod_rewrite.so • modules/mod_jk.so

El modulo mod_jk estable recomendado para entornos de producción es la versión jk-1.2.26. Generalmente los dos primeros módulos siempre vienen instalados y habilitados en el fichero de configuración de Apache, mientras que el último suele ser necesario instalarlo manualmente. 3.1.2. Ficheros de configuración httpd.conf Normalmente la ruta del fichero será /etc/httpd/conf/httpd.conf. La configuración habilitada en cada CCAA será distinta, sin embargo, podemos referenciar los parámetros de configuración que afectan o necesita directamente el portal Agrega: # KeepAlive: Whether or not to allow persistent connections (more than # one request per connection). Set to "Off" to deactivate. # KeepAlive On Con este parámetro habilitamos las conexiones persistentes.

93

Mediante el comando httpd –V podemos comprobar cómo se encuentra configurado el servidor MPM de Apache. Un ejemplo de la salida del comando es la siguiente: Server version: Apache/2.0.52 Server built: May 24 2006 11:45:10 Server's Module Magic Number: 20020903:9 Architecture: 32-bit Server compiled with.... -D APACHE_MPM_DIR="server/mpm/prefork" … Si el server MPM configurado es prefork, desde la wiki oficial de JBoss donde se especifica la configuración óptima para el módulo mod-jk se aconseja el valor de 200 clientes por cada CPU que tenga el servidor. En el caso de un servidor con 2 procesadores se aconsejarían los siguientes valores: <IfModule prefork.c> StartServers 20 MinSpareServers 20 MaxSpareServers 20 ServerLimit 400 MaxClients 400 MaxRequestsPerChild 0 </IfModule> Si en lugar de prefork la configuración del server MPM es worker, modificaríamos las siguientes líneas: <IfModule worker.c> StartServers 2 MaxClients 400 MinSpareThreads 25 MaxSpareThreads 75 ThreadsPerChild 25 MaxRequestsPerChild 0 </IfModule> Posteriormente, comprobamos que se encuentren cargados los siguientes módulos: LoadModule deflate_module modules/mod_deflate.so LoadModule alias_module modules/mod_alias.so LoadModule rewrite_module modules/mod_rewrite.so LoadModule jk_module modules/mod_jk.so El modulo mod-jk podría no estar configurado directamente en el httpd.conf y ser configurado en ficheros “.conf” independientes en el directorio /etc/httpd/conf.d/ si se encuentran presentes por ejemplo las líneas: Include conf.d/*.conf Include vhosts.d/*.conf En este caso estamos especificando también el directorio donde se almacenarán los ficheros que definen los virtual hosts (/etc/httpd/vhosts.d/).

94

worker.properties En el directorio /etc/httpd/conf se suele almacenar el fichero que contiene la definición de los workers del módulo mod-jk donde se definen las conexiones entre el Apache y el servidor de aplicaciones JBoss. Su contenido es el siguiente: worker.list=<nodo> worker.<nodo>.host=<ip_jboss> worker.<nodo>.type=ajp13 worker.<nodo>.port=8009 worker.<nodo>.connect_timeout=10000 worker.<nodo>.prepost_timeout=10000 worker.<nodo>.socket_timeout=10 #This value must equal server.xml's connectionTimeout of 10 minutes worker.<nodo>.connection_pool_timeout=600 En donde:

• <nodo> será el nombre de la CCAA donde nos encontremos, pero puede tener cualquier valor.

• <ip_jboss> es la dirección IP donde escucha el conector AJP del JBoss. Los tiempos máximos de espera son los aconsejados en la wiki oficial de JBoss para situaciones de alta carga. El valor del connection_pool_timeout ha de ser igual al valor configurado en el fichero server.xml del JBoss (cuidado que este tiempo se define en segundos y el otro en milisegundos). mod_jk.conf En el caso de especificar el fichero de mod_jk.conf en el directorio conf.d mediante la sentencia include en el httpd.conf, el fichero mod_jk.conf tendría el siguiente contenido: # Load mod_jk module # Specify the filename of the mod_jk lib LoadModule jk_module modules/mod_jk.so # Where to find workers.properties JkWorkersFile "/etc/httpd/conf/workers.properties" # Where to put jk logs JkLogFile "/var/log/httpd/mod_jk.log" # Set the jk log level [debug/error/info] JkLogLevel info # Select the log format JkLogStampFormat "[%a %b %d %H:%M:%S %Y]" # JkOptions indicates to send SSK KEY SIZE # Note: Changed from +ForwardURICompat. # See http://tomcat.apache.org/security-jk.html JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories # JkRequestLogFormat

95

JkRequestLogFormat "%w %V %T" # Mount your applications #JkMount /__application__/* loadbalancer # You can use external file for mount points. # It will be checked for updates each 60 seconds. # The format of the file is: /url=worker # /examples/*=loadbalancer #JkMountFile conf/uriworkermap.properties # Add shared memory. # This directive is present with 1.2.10 and # later versions of mod_jk, and is needed for # for load balancing to work properly # Note: Replaced JkShmFile logs/jk.shm due to SELinux issues. Refer to # https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225452 JkShmFile run/jk.shm Las tres líneas resaltadas son aquellas susceptibles a ser modificadas en cada CCAA, especificando:

• La ubicación del módulo y el nombre del mismo. • La ruta completa al fichero worker.properties. • Fichero de log del módulo mod_jk.

vhost En el directorio /etc/httpd/vhosts.d/ se creará un virtual host diferente en cada CCAA. La plantilla desde la que se parte durante la instalación es la que sigue a continuación: <VirtualHost *:80> DocumentRoot "/export/ccaa/<sitio>/uploads" ServerName <nodo> ServerAlias <nodo> <nodo>.agrega.indra.es Definimos el virtual host que escucha en todas las direcciones ip, puerto 80. Especificamos el DocumentRoot del virtual host apuntando al directorio uploads del portal (normalmente será un directorio dentro del disco compartido por NFS). Por último, definimos el ServerName y ServerAlias del nodo con los valores adecuados. Alias /static/css /opt/static/ccaa/<sitio>/css Alias /static /opt/static/common Alias /log /opt/log/<sitio> Alias /wiki /export/wiki/wiki Alias /wiki-ca /export/wiki/wiki-ca Alias /wiki-en /export/wiki/wiki-en Alias /wiki-eu /export/wiki/wiki-eu Alias /wiki-gl /export/wiki/wiki-gl Alias /wiki-va /export/wiki/wiki-va

96

Definimos los siguientes alias:

• Si deseamos que Apache sirva el contenido estático del portal (imágenes comunes, logos, plantillas, CSS, JS…) es necesario crear los alias static y static/css a los directorios que contienen los estáticos facilitados durante la instalación. En caso contrario, sería necesario añadir la línea siguiente en la sección de configuración de los puntos de montaje mod-jk:

JkMount /static/* <nodo>

• Puesto que los logs se almacenarán por lo general en una partición

diferente a la del JBoss (para evitar que se llene el espacio en disco), la aplicación necesita que el alias del vhost /log apunte al directorio donde se almacenan realmente los logs del aplicativo JBossAS.

• La ayuda, necesita tantos alias como wikis internacionalizadas existen. Recordamos que se trata de una aplicación PHP y apuntará al directorio donde se encuentren instaladas.

Alias /taller /export/ccaa/<sitio>/uploads/taller Alias /noticias /export/ccaa/<sitio>/uploads/noticias Alias /repositorio /export/ccaa/<sitio>/uploads/repositorio Alias /galeriaimg /export/ccaa/<sitio>/uploads/galeriaimg/<sitio> Alias /imgcommon /export/ccaa/<sitio>/uploads/galeriaimg/common Alias /imagenesInformes /export/ccaa/<sitio>/uploads/imagenesInformes Alias /rss /export/ccaa/<sitio>/uploads/rss Alias /utilidades /export/ccaa/<sitio>/uploads/utilidades Alias /searchPlugin /export/ccaa/<sitio>/uploads/searchPlugin Alias /sitemaps /export/ccaa/<sitio>/uploads/sitemaps Alias /informesPortada /export/ccaa/<sitio>/uploads/informesPortada Alias /descargas /export/ccaa/<sitio>/uploads/descargas Definimos el resto de los alias usados en el portal. La mayor parte de ellos apuntan a directorios contenidos dentro de uploads. # security # forbid default access to filesystem locations <Directory /> Order Deny,Allow Deny from all Options FollowSymLinks AllowOverride None php_flag engine off </Directory> Definimos el directorio raíz configurado mediante los parámetros:

• Deny from all No permitimos conexiones al directorio DocumentRoot

• AllowOverride None Ignoramos los ficheros .htaccess para evitar que sobrescriban políticas de seguridad.

97

• php_flag engine off

Desactivamos la ejecución de código php. Evitamos que alguien pueda subir recursos ODEs con código PHP malicioso y pueda ejecutarlos.

<Directory "/opt/static"> Order Deny,Allow Allow from all Options FollowSymLinks AllowOverride None php_flag engine off </Directory> <Directory "/export/ccaa/<sitio>/uploads"> Order Deny,Allow Allow from all AllowOverride None Options FollowSymLinks php_flag engine off </Directory> Se definen los directorios del /opt/static y directorio uploads. <Directory "/export/wiki/wiki/"> Options None AllowOverride None Order Deny,Allow Allow from all php_flag engine on </Directory> <Directory "/export/wiki/wiki-ca/"> Options None AllowOverride None Order Deny,Allow Allow from all php_flag engine on </Directory> <Directory "/export/wiki/wiki-en/"> Options None AllowOverride None Order Deny,Allow Allow from all php_flag engine on </Directory> <Directory "/export/wiki/wiki-eu/"> Options None AllowOverride None Order Deny,Allow Allow from all php_flag engine on </Directory> <Directory "/export/wiki/wiki-gl/"> Options None AllowOverride None Order Deny,Allow

98

Allow from all php_flag engine on </Directory> <Directory "/export/wiki/wiki-va/"> Options None AllowOverride None Order Deny,Allow Allow from all php_flag engine on </Directory> A continuación se han definido todos los directorios donde se encuentran instaladas las MediaWiki. Es importante destacar que es necesario habilitar el php_flag engine puesto que se trata de un software PHP. RewriteEngine on RewriteRule ^/robots.txt$ /sitemaps/robots.txt [L,PT] RewriteRule ^/sitemap.xml$ /sitemaps/sitemap-index.xml [L,PT] RewriteRule ^/sitemap(.*).xml$ /sitemaps/sitemap$1.xml [L,PT] RewriteRule ^/$ /visualizadorcontenidos/ [R=permanent,L] RewriteRule ^/layout/(.*) /visualizador-1/layout/$1 [L,PT] #RewriteRule ^/idODE/([a-z_][0-9]+)/ /visualizador-1/Visualizar/Visualizar.do?identificador=$1&secuencia=false [L,PT] RewriteRule ^/idODE/(.*) /visualizador-1/Visualizar/Visualizar.do?identificador=$1&secuencia=false [L,PT] # ODE/<idioma>/<identificadorODE> ---- Example: http://mantenimiento.agrega.indra.es/ODE/es/es-mec_20080206_3_9220808 RewriteRule ^/ODE/(.+)/(.+)$ /buscador/BuscarAvanzadoCU/MostrarResultadosAvanzadoPrepararRetornoDetalle.do?idioma=$1&identificadorODE=$2 [L,PT] RewriteRule ^/visualizar/es/(.+)\.jsp$ /visualizador-1/$1\.jsp [PT,L] RewriteRule ^/visualizar/es/(.+)\.html$ /visualizador-1/$1\.html [PT,L] RewriteRule ^/visualizar/en/(.+)\.jsp$ /visualizador-1/$1\.jsp [PT,L] RewriteRule ^/visualizar/en/(.+)\.html$ /visualizador-1/$1\.html [PT,L] RewriteRule ^/visualizar/eu/(.+)\.jsp$ /visualizador-1/$1\.jsp [PT,L] RewriteRule ^/visualizar/eu/(.+)\.html$ /visualizador-1/$1\.html [PT,L] RewriteRule ^/visualizar/ca/(.+)\.jsp$ /visualizador-1/$1\.jsp [PT,L] RewriteRule ^/visualizar/ca/(.+)\.html$ /visualizador-1/$1\.html [PT,L] RewriteRule ^/visualizar/va/(.+)\.jsp$ /visualizador-1/$1\.jsp [PT,L] RewriteRule ^/visualizar/va/(.+)\.html$ /visualizador-1/$1\.html [PT,L] RewriteRule ^/visualizar/gl/(.+)\.jsp$ /visualizador-1/$1\.jsp [PT,L] RewriteRule ^/visualizar/gl/(.+)\.html$ /visualizador-1/$1\.html [PT,L] # visualizar/<identificadorODE>/<sequence> ---- Example: http://mantenimiento.agrega.indra.es/visualizar/es-mec_20080206_3_9220808/false RewriteRule ^/visualizar/(.+)/(.+)/(.+)$ /visualizador-1/Visualizar/Visualizar.do?idioma=$1&identificador=$2&secuencia=$3 [L,PT] # Reglas de rewriting para las NOTICIAS RewriteRule ^/portada/noticias/(.+)/(.+)$ /visualizadorcontenidos/Portada/NoticiasVer.do?id=$2 [PT,L] RewriteRule ^/portada/noticiasCategorias/(.+)/(.+)$ /visualizadorcontenidos/Portada/NoticiasCategoria.do?idCategoria=$2 [PT,L] RewriteRule ^/noticias$ /visualizadorcontenidos/Noticias/Noticias.do [PT,L] RewriteCond %{QUERY_STRING} ^idCategoria(.+)&(.+)$ RewriteRule ^/noticias/categorias/(.+)/(.+)$

99

/visualizadorcontenidos/Noticia/NoticiaCategoria.do?idCategoria%1&%2 [PT,L] RewriteCond %{QUERY_STRING} ^(.+)&idCategoria(.+)$ RewriteRule ^/noticias/categorias/(.+)/(.+)$ /visualizadorcontenidos/Noticia/NoticiaCategoria.do?%1&idCategoria%2 [PT,L] RewriteRule ^/noticias/categorias/(.+)/(.+)$ /visualizadorcontenidos/Noticia/NoticiaCategoria.do?idCategoria=$2 [PT,L] Definimos un conjunto de RewriteRules para facilitar las URLs y su almacenamiento como favoritos en sistemas externos. El formato de una RewriteRule es: RewriteRule Pattern Substitution [Flags] Donde los flags más comunes son:

• L: Last Rule. Si la regla se ejecutó, no se ejecutan más reglas posteriormente.

• PT: Pass Through al próximo controlador. Permite el post-procesamiento de la salida de la rewrite rule usando Alias, ScriptAlias, Redirect…

#JkLogLevel debug JkMount /visualizadorcontenidos/* <nodo> JkMount /PortalEmpaquetador/* <nodo> JkMount /catalogadorWeb/* <nodo> JkMount /visualizador-1/* <nodo> JkMount /portaladministracion/* <nodo> JkMount /buscador/* <nodo> JkMount /dri-1/* <nodo> JkMount /gestorFlujo/* <nodo> JkMount /buscar-1/* <nodo> JkMount /reputacion/* <nodo> JkMount /auditoria/* <nodo> JkMount /ModificadorWeb/* <nodo> JkMount /oaipmh/* <nodo> Definimos los módulos que se conectarán al JBoss presente en el <nodo> definido en el worker.properties. Toda petición que se dirija a cualquiera de estos paths en la URL, será redirigida la petición hacia el JBoss a través del conector AJP. LogFormat "%h %l %u %t \"%r\" %>s %b" extendedlog CustomLog logs/<sitio>_access.log extendedlog ErrorLog logs/<sitio>_error.log </VirtualHost> Definimos el virtual host asociado al cas (módulo de autenticación que nos proporciona single sign on), que podría encontrarse en otro servidor, aunque normalmente residirá en el mismo que el portal. <VirtualHost *:80>

100

ServerName cas-<nodo>.agrega.indra.es JkMount /cas/* <nodo> Alias /static/css /opt/static/ccaa/<sitio>/css Alias /static /opt/static/common LogFormat "%h %l %u %t \"%r\" %>s %b" extendedlog CustomLog logs/<sitio>_access.log extendedlog ErrorLog logs/<sitio>_error.log </VirtualHost> Por ultimo se define un virtual host para el cas mediante protocolo seguro (HTTPS, 443): <VirtualHost *:443> ServerName cas-<nodo>.agrega.indra.es JkMount /cas/* <nodo> Alias /static/css /opt/static/ccaa/<sitio>/css Alias /static /opt/static/common LogFormat "%h %l %u %t \"%r\" %>s %b" extendedlog CustomLog logs/<sitio>_access.log extendedlog ErrorLog logs/<sitio>_error.log </VirtualHost> 3.2. Ayuda MediaWiki La ayuda de la plataforma Agrega hace uso de la aplicación basada en software libre MediaWiki. La aplicación MediaWiki 1.12.0 se ejecuta durante el proceso de instalación del nodo. Para el correcto funcionamiento, requiere PHP 5 o superior y la conexión a una base de datos (normalmente MySQL). Por todo ello, se trata de una aplicación disjunta del portal con una base de datos diferente a la del portal, en la que no se comparte directamente la información entre ambas aplicaciones. 3.2.1. Proceso de instalación Durante la instalación, en un directorio visible desde la máquina de Apache y habiendo configurado el soporte para PHP 5 o superior, se descomprimirán los binarios de la aplicación Mediawiki por ejemplo en el directorio /export/wiki. Se recomienda que el dueño del directorio sea el usuario que ejecuta Apache en la máquina. Una vez descomprimidos los binarios, en la base de datos crearemos una nueva

101

entrada para la wiki, por ejemplo: base de datos wikidb. A través de un dump proporcionado procederemos a volcar toda la información, tablas e índices necesarios mediante el comando: mysql -u root -p wikidb < wikidb.sql Se habrá creado un usuario de acceso a la base de datos de la wiki con permisos de inserción, modificación y borrado de entradas en las tablas, pero no con privilegios de modificación de los esquemas mediante el comando: grant insert, update, delete, select on wikidb.* to wiki_user@'localhost' identified by 'password' 3.2.2. Ficheros de configuración Los únicos 2 ficheros a tener en cuenta para la correcta configuración de la MediaWiki son los siguientes: /export/wiki/LocalSettings.php Almacena toda la configuración de la wiki, entre los parámetros más importantes destacamos los siguientes: $wgDBserver = "servidor"; $wgDBname = "wikidb"; $wgDBuser = "usuario_wiki"; $wgDBpassword = "pass_wiki"; $wgDBprefix = ""; $wgDBtype = "mysql"; Especificamos el servidor que contiene la BD, el nombre de la base de datos, el usuario y password de la conexión y el tipo de base de datos al que nos conectamos. $wgLanguageCode = "Es"; Dado que existirá una wiki por cada idioma, en cada instalación MediaWiki se deberá especificar el idioma correspondiente, pudiendo tomar los siguientes valores:

Idioma Prefijo Castellano Es Catalán Ca Euskera Eu Gallego Gl Inglés En Valenciano Ca

vhost especificado en Apache Recordamos que se debe definir tanto el Alias como el Directorio donde se encuentre instalada la MediaWiki con permisos de ejecución php. Asumiendo que la wiki se encuentra instalada en /export/wiki/wikies: Alias /wiki /export/wiki/wikies

102

<Directory "/export/wiki/wikies/"> Options None AllowOverride None Order Deny,Allow Allow from all php_flag engine on </Directory> 3.2.3. Internacionalización Existirán tantas MediaWiki instaladas como idiomas internacionalizados deseemos ofrecer. Por defecto se habrán instalado 6 MediaWiki, para los idiomas castellano, catalán, euskera, gallego, inglés y valenciano. Los alias que usará el portal para redirigir a la ayuda serán:

Idioma Prefijo Castellano /wiki Catalán /wiki-ca Euskera /wiki-eu Gallego /wiki-gl Inglés /wiki-en Valenciano /wiki-va

3.3. Proxy cache: Squid En algunas ocasiones, puede ser conveniente instalar un Proxy caché intermedio (antes de Apache) para almacenar aquellas peticiones que se repitan muchas veces a lo largo del tiempo. Las respuestas del portal HTTP se encuentran bien formadas y permiten su almacenamiento tanto en la caché del navegador como en las caches intermedias existentes. Veamos la siguiente figura:

103

Un usuario posee una cache de navegación habilitada para no volver a pedir aquellos ficheros que no se han modificado desde la última vez que se solicitaron, se conecta a través de un proveedor de servicios de Internet (ISP), que suele disponer de pooles de cache bastante extensos con el fin de limitar el tráfico saliente de su red hacia Internet. Si el recurso solicitado no se encuentra en la cache del ISP se pedirá a través de Internet el recurso, llegando finalmente a la CCAA la petición. Como norma general aconsejamos que exista una cache lo más cerca al usuario como sea posible, para evitar tráfico por las redes y tiempos de respuesta mayores. Por ello, la cache más efectiva es en primer lugar la del navegador del usuario, luego al del ISP y por último la de la CCAA. Las cabeceras HTTP que controlan la posibilidad de Cache o no son:

• Peticiones salientes: If-modified-since

• Respuestas:

Last-Modified Cache-Control Expires

Veamos un ejemplo real capturado con el plugin de Firefox Live HTTP Headers. Si borramos la caché del usuario y solicitamos al portal redes la página inicial vemos el siguiente tráfico intercambiado: http://redes.agrega.indra.es/ GET / HTTP/1.1

104

Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive HTTP/1.x 301 Moved Permanently Date: Tue, 30 Sep 2008 07:56:31 GMT Server: Apache/2.0.52 (Red Hat) Location: http://redes.agrega.indra.es/visualizadorcontenidos/ Content-Length: 348 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html; charset=iso-8859-1 ---------------------------------------------------------- http://redes.agrega.indra.es/visualizadorcontenidos/ GET /visualizadorcontenidos/ HTTP/1.1 Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive HTTP/1.x 302 Movido temporálmente Date: Tue, 30 Sep 2008 07:56:31 GMT Server: Apache/2.0.52 (Red Hat) X-Powered-By: Servlet 2.4; JBoss-4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)/Tomcat-5.5 Set-Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48; Path=/ Location: http://redes.agrega.indra.es/visualizadorcontenidos/Portada/Portada.do;jsessionid=62F1FE67D9BCC35F09C7EF4DF0521D48 Content-Length: 0 Keep-Alive: timeout=15, max=99 Connection: Keep-Alive Content-Type: text/html;charset=ISO-8859-1 ---------------------------------------------------------- http://redes.agrega.indra.es/visualizadorcontenidos/Portada/Portada.do;jsessionid=62F1FE67D9BCC35F09C7EF4DF0521D48 GET /visualizadorcontenidos/Portada/Portada.do;jsessionid=62F1FE67D9BCC35F09C7EF4DF0521D48 HTTP/1.1 Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate

105

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48 HTTP/1.x 200 OK Date: Tue, 30 Sep 2008 07:56:31 GMT Server: Apache/2.0.52 (Red Hat) X-Powered-By: Servlet 2.4; JBoss-4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)/Tomcat-5.5 Content-Language: es-ES Keep-Alive: timeout=15, max=98 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html;charset=ISO-8859-1 ---------------------------------------------------------- http://redes.agrega.indra.es/static/img/favicon.ico GET /static/img/favicon.ico HTTP/1.1 Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: image/png,image/*;q=0.8,*/*;q=0.5 Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48 HTTP/1.x 200 OK Date: Tue, 30 Sep 2008 07:56:31 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Mon, 11 Aug 2008 11:21:52 GMT Etag: "f02cb-e36-5cadd400" Accept-Ranges: bytes Content-Length: 3638 Keep-Alive: timeout=15, max=97 Connection: Keep-Alive Content-Type: text/plain ---------------------------------------------------------- http://redes.agrega.indra.es/static/js/plantilla.js GET /static/js/plantilla.js HTTP/1.1 Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: */* Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://redes.agrega.indra.es/visualizadorcontenidos/Portada/Portada.do;jsessionid=62F1FE67D9BCC35F09C7EF4DF0521D48 Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48

106

HTTP/1.x 200 OK Date: Tue, 30 Sep 2008 07:56:31 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Thu, 07 Aug 2008 10:40:44 GMT Etag: "f0202-33d-5235a300" Accept-Ranges: bytes Content-Length: 829 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: application/x-javascript ---------------------------------------------------------- http://redes.agrega.indra.es/static/css/red.css GET /static/css/red.css HTTP/1.1 Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: text/css,*/*;q=0.1 Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://redes.agrega.indra.es/visualizadorcontenidos/Portada/Portada.do;jsessionid=62F1FE67D9BCC35F09C7EF4DF0521D48 Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48 HTTP/1.x 200 OK Date: Tue, 30 Sep 2008 07:56:31 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Thu, 07 Aug 2008 10:11:36 GMT Etag: "f0209-32191-ea054600" Accept-Ranges: bytes Content-Length: 205201 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/css ---------------------------------------------------------- http://redes.agrega.indra.es/static/js/mootools.js GET /static/js/mootools.js HTTP/1.1 Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: */* Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://redes.agrega.indra.es/visualizadorcontenidos/Portada/Portada.do;jsessionid=62F1FE67D9BCC35F09C7EF4DF0521D48 Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48 HTTP/1.x 200 OK Date: Tue, 30 Sep 2008 07:56:32 GMT

107

Server: Apache/2.0.52 (Red Hat) Last-Modified: Thu, 05 Jun 2008 11:56:00 GMT Etag: "f0201-a8c3-761b400" Accept-Ranges: bytes Content-Length: 43203 Keep-Alive: timeout=15, max=96 Connection: Keep-Alive Content-Type: application/x-javascript ---------------------------------------------------------- http://redes.agrega.indra.es/static/js/calendar.rc4.js GET /static/js/calendar.rc4.js HTTP/1.1 Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: */* Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://redes.agrega.indra.es/visualizadorcontenidos/Portada/Portada.do;jsessionid=62F1FE67D9BCC35F09C7EF4DF0521D48 Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48 HTTP/1.x 200 OK Date: Tue, 30 Sep 2008 07:56:32 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Tue, 05 Aug 2008 15:43:46 GMT Etag: "f01fc-88df-52423080" Accept-Ranges: bytes Content-Length: 35039 Keep-Alive: timeout=15, max=99 Connection: Keep-Alive Content-Type: application/x-javascript ---------------------------------------------------------- http://redes.agrega.indra.es/static/img/senal.gif GET /static/img/senal.gif HTTP/1.1 Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: image/png,image/*;q=0.8,*/*;q=0.5 Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://redes.agrega.indra.es/static/css/red.css Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48 HTTP/1.x 200 OK Date: Tue, 30 Sep 2008 07:56:32 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Tue, 27 May 2008 08:57:22 GMT Etag: "f036a-166-7bf7a080" Accept-Ranges: bytes

108

Content-Length: 358 Keep-Alive: timeout=15, max=99 Connection: Keep-Alive Content-Type: image/gif ---------------------------------------------------------- http://redes.agrega.indra.es/static/img/buscador_widget.gif GET /static/img/buscador_widget.gif HTTP/1.1 Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: image/png,image/*;q=0.8,*/*;q=0.5 Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://redes.agrega.indra.es/static/css/red.css Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48 HTTP/1.x 200 OK Date: Tue, 30 Sep 2008 07:56:32 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Tue, 27 May 2008 08:56:40 GMT Etag: "f029f-4de-7976c200" Accept-Ranges: bytes Content-Length: 1246 Keep-Alive: timeout=15, max=95 Connection: Keep-Alive Content-Type: image/gif ---------------------------------------------------------- http://redes.agrega.indra.es/static/img/cabecera.jpg GET /static/img/cabecera.jpg HTTP/1.1 Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: image/png,image/*;q=0.8,*/*;q=0.5 Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://redes.agrega.indra.es/static/css/red.css Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48 HTTP/1.x 200 OK Date: Tue, 30 Sep 2008 07:56:32 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Thu, 01 Mar 2007 17:15:36 GMT Etag: "f02a2-146-a3acfe00" Accept-Ranges: bytes Content-Length: 326 Keep-Alive: timeout=15, max=98 Connection: Keep-Alive Content-Type: image/jpeg ---------------------------------------------------------- http://redes.agrega.indra.es/static/img/barrita.gif

109

GET /static/img/barrita.gif HTTP/1.1 Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: image/png,image/*;q=0.8,*/*;q=0.5 Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://redes.agrega.indra.es/static/css/red.css Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48 HTTP/1.x 200 OK Date: Tue, 30 Sep 2008 07:56:32 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Mon, 30 Oct 2006 15:44:32 GMT Etag: "f0292-2d-255b3800" Accept-Ranges: bytes Content-Length: 45 Keep-Alive: timeout=15, max=98 Connection: Keep-Alive Content-Type: image/gif ---------------------------------------------------------- http://redes.agrega.indra.es/static/img/06_ingles.gif GET /static/img/06_ingles.gif HTTP/1.1 Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: image/png,image/*;q=0.8,*/*;q=0.5 Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://redes.agrega.indra.es/static/css/red.css Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48 HTTP/1.x 200 OK Date: Tue, 30 Sep 2008 07:56:32 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Mon, 26 May 2008 16:24:20 GMT Etag: "f0285-5e-9c9a7500" Accept-Ranges: bytes Content-Length: 94 Keep-Alive: timeout=15, max=94 Connection: Keep-Alive Content-Type: image/gif ---------------------------------------------------------- http://redes.agrega.indra.es/static/img/04_valenciano.gif GET /static/img/04_valenciano.gif HTTP/1.1 Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: image/png,image/*;q=0.8,*/*;q=0.5

110

Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://redes.agrega.indra.es/static/css/red.css Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48 HTTP/1.x 200 OK Date: Tue, 30 Sep 2008 07:56:32 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Mon, 26 May 2008 16:23:40 GMT Etag: "f0281-4c-9a381b00" Accept-Ranges: bytes Content-Length: 76 Keep-Alive: timeout=15, max=97 Connection: Keep-Alive Content-Type: image/gif ---------------------------------------------------------- http://redes.agrega.indra.es/static/img/05_vasco.gif GET /static/img/05_vasco.gif HTTP/1.1 Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: image/png,image/*;q=0.8,*/*;q=0.5 Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://redes.agrega.indra.es/static/css/red.css Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48 HTTP/1.x 200 OK Date: Tue, 30 Sep 2008 07:56:32 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Mon, 26 May 2008 16:23:58 GMT Etag: "f0283-5a-9b4ac380" Accept-Ranges: bytes Content-Length: 90 Keep-Alive: timeout=15, max=97 Connection: Keep-Alive Content-Type: image/gif ---------------------------------------------------------- http://redes.agrega.indra.es/static/img/03_gallego.gif GET /static/img/03_gallego.gif HTTP/1.1 Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: image/png,image/*;q=0.8,*/*;q=0.5 Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://redes.agrega.indra.es/static/css/red.css

111

Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48 HTTP/1.x 200 OK Date: Tue, 30 Sep 2008 07:56:32 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Mon, 26 May 2008 16:23:00 GMT Etag: "f027f-50-97d5c100" Accept-Ranges: bytes Content-Length: 80 Keep-Alive: timeout=15, max=93 Connection: Keep-Alive Content-Type: image/gif ---------------------------------------------------------- http://redes.agrega.indra.es/static/img/02_catalan.gif GET /static/img/02_catalan.gif HTTP/1.1 Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: image/png,image/*;q=0.8,*/*;q=0.5 Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://redes.agrega.indra.es/static/css/red.css Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48 HTTP/1.x 200 OK Date: Tue, 30 Sep 2008 07:56:32 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Mon, 26 May 2008 16:22:34 GMT Etag: "f027d-3d-96490680" Accept-Ranges: bytes Content-Length: 61 Keep-Alive: timeout=15, max=96 Connection: Keep-Alive Content-Type: image/gif ---------------------------------------------------------- http://redes.agrega.indra.es/static/img/01_castellano.gif GET /static/img/01_castellano.gif HTTP/1.1 Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: image/png,image/*;q=0.8,*/*;q=0.5 Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://redes.agrega.indra.es/static/css/red.css Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48 HTTP/1.x 200 OK Date: Tue, 30 Sep 2008 07:56:32 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Mon, 26 May 2008 16:21:26 GMT

112

Etag: "f027b-3a-923b6d80" Accept-Ranges: bytes Content-Length: 58 Keep-Alive: timeout=15, max=96 Connection: Keep-Alive Content-Type: image/gif ---------------------------------------------------------- http://redes.agrega.indra.es/static/img/logo_redes.gif GET /static/img/logo_redes.gif HTTP/1.1 Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: image/png,image/*;q=0.8,*/*;q=0.5 Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://redes.agrega.indra.es/static/css/red.css Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48 HTTP/1.x 200 OK Date: Tue, 30 Sep 2008 07:56:32 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Thu, 06 Mar 2008 10:32:38 GMT Etag: "f0337-153d-41ae1d80" Accept-Ranges: bytes Content-Length: 5437 Keep-Alive: timeout=15, max=92 Connection: Keep-Alive Content-Type: image/gif ---------------------------------------------------------- http://redes.agrega.indra.es/static/img/barra_general.gif GET /static/img/barra_general.gif HTTP/1.1 Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: image/png,image/*;q=0.8,*/*;q=0.5 Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://redes.agrega.indra.es/static/css/red.css Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48 HTTP/1.x 200 OK Date: Tue, 30 Sep 2008 07:56:32 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Fri, 02 Mar 2007 18:19:00 GMT Etag: "f028f-40b-a440cd00" Accept-Ranges: bytes Content-Length: 1035 Keep-Alive: timeout=15, max=95 Connection: Keep-Alive Content-Type: image/gif

113

---------------------------------------------------------- http://redes.agrega.indra.es/static/img/barra_general_der.gif GET /static/img/barra_general_der.gif HTTP/1.1 Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: image/png,image/*;q=0.8,*/*;q=0.5 Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://redes.agrega.indra.es/static/css/red.css Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48 HTTP/1.x 200 OK Date: Tue, 30 Sep 2008 07:56:32 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Fri, 02 Mar 2007 18:24:36 GMT Etag: "f0290-108-b847c100" Accept-Ranges: bytes Content-Length: 264 Keep-Alive: timeout=15, max=95 Connection: Keep-Alive Content-Type: image/gif ---------------------------------------------------------- http://redes.agrega.indra.es/static/img/bullet_off.gif GET /static/img/bullet_off.gif HTTP/1.1 Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: image/png,image/*;q=0.8,*/*;q=0.5 Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://redes.agrega.indra.es/static/css/red.css Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48 HTTP/1.x 200 OK Date: Tue, 30 Sep 2008 07:56:32 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Fri, 02 Mar 2007 12:14:40 GMT Etag: "f029d-43-8d4bac00" Accept-Ranges: bytes Content-Length: 67 Keep-Alive: timeout=15, max=91 Connection: Keep-Alive Content-Type: image/gif ---------------------------------------------------------- http://redes.agrega.indra.es/static/img/dest_01.jpg GET /static/img/dest_01.jpg HTTP/1.1 Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1)

114

Gecko/2008070208 Firefox/3.0.1 Accept: image/png,image/*;q=0.8,*/*;q=0.5 Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://redes.agrega.indra.es/static/css/red.css Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48 HTTP/1.x 200 OK Date: Tue, 30 Sep 2008 07:56:32 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Thu, 01 Mar 2007 17:12:36 GMT Etag: "f02b8-2aa4-98f26900" Accept-Ranges: bytes Content-Length: 10916 Keep-Alive: timeout=15, max=94 Connection: Keep-Alive Content-Type: image/jpeg ---------------------------------------------------------- http://redes.agrega.indra.es/static/img/imagen_00.jpg GET /static/img/imagen_00.jpg HTTP/1.1 Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: image/png,image/*;q=0.8,*/*;q=0.5 Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://redes.agrega.indra.es/static/css/red.css Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48 HTTP/1.x 200 OK Date: Tue, 30 Sep 2008 07:56:32 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Tue, 24 Jun 2008 10:42:56 GMT Etag: "f030c-140fd-390f4c00" Accept-Ranges: bytes Content-Length: 82173 Keep-Alive: timeout=15, max=94 Connection: Keep-Alive Content-Type: image/jpeg ---------------------------------------------------------- http://redes.agrega.indra.es/static/img/00_logo_gobierno.gif GET /static/img/00_logo_gobierno.gif HTTP/1.1 Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: image/png,image/*;q=0.8,*/*;q=0.5 Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300

115

Connection: keep-alive Referer: http://redes.agrega.indra.es/static/css/red.css Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48 HTTP/1.x 200 OK Date: Tue, 30 Sep 2008 07:56:32 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Mon, 02 Jun 2008 08:10:14 GMT Etag: "f0277-b9e-86740580" Accept-Ranges: bytes Content-Length: 2974 Keep-Alive: timeout=15, max=90 Connection: Keep-Alive Content-Type: image/gif ---------------------------------------------------------- http://redes.agrega.indra.es/static/img/00_logo_mepd.gif GET /static/img/00_logo_mepd.gif HTTP/1.1 Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: image/png,image/*;q=0.8,*/*;q=0.5 Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://redes.agrega.indra.es/static/css/red.css Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48 HTTP/1.x 200 OK Date: Tue, 30 Sep 2008 07:56:32 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Mon, 02 Jun 2008 08:11:14 GMT Etag: "f0278-74f-8a078c80" Accept-Ranges: bytes Content-Length: 1871 Keep-Alive: timeout=15, max=93 Connection: Keep-Alive Content-Type: image/gif ---------------------------------------------------------- http://redes.agrega.indra.es/static/img/00_logo_red.jpg GET /static/img/00_logo_red.jpg HTTP/1.1 Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: image/png,image/*;q=0.8,*/*;q=0.5 Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://redes.agrega.indra.es/static/css/red.css Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48 HTTP/1.x 200 OK Date: Tue, 30 Sep 2008 07:56:32 GMT

116

Server: Apache/2.0.52 (Red Hat) Last-Modified: Mon, 21 Apr 2008 07:33:06 GMT Etag: "f027a-5d1-1c51b080" Accept-Ranges: bytes Content-Length: 1489 Keep-Alive: timeout=15, max=89 Connection: Keep-Alive Content-Type: image/jpeg ---------------------------------------------------------- http://redes.agrega.indra.es/static/img/00_logo_avanza.jpg GET /static/img/00_logo_avanza.jpg HTTP/1.1 Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: image/png,image/*;q=0.8,*/*;q=0.5 Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://redes.agrega.indra.es/static/css/red.css Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48 HTTP/1.x 200 OK Date: Tue, 30 Sep 2008 07:56:32 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Mon, 21 Apr 2008 07:33:44 GMT Etag: "f0274-6bc-1e958600" Accept-Ranges: bytes Content-Length: 1724 Keep-Alive: timeout=15, max=92 Connection: Keep-Alive Content-Type: image/jpeg ---------------------------------------------------------- http://redes.agrega.indra.es/static/img/00_logo_mitc.gif GET /static/img/00_logo_mitc.gif HTTP/1.1 Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: image/png,image/*;q=0.8,*/*;q=0.5 Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://redes.agrega.indra.es/static/css/red.css Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48 HTTP/1.x 200 OK Date: Tue, 30 Sep 2008 07:56:32 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Mon, 02 Jun 2008 08:11:38 GMT Etag: "f0279-650-8b75c280" Accept-Ranges: bytes Content-Length: 1616 Keep-Alive: timeout=15, max=100

117

Connection: Keep-Alive Content-Type: image/gif ---------------------------------------------------------- http://redes.agrega.indra.es/static/img/00_logo_europa.gif GET /static/img/00_logo_europa.gif HTTP/1.1 Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: image/png,image/*;q=0.8,*/*;q=0.5 Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://redes.agrega.indra.es/static/css/red.css Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48 HTTP/1.x 200 OK Date: Tue, 30 Sep 2008 07:56:32 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Mon, 02 Jun 2008 08:12:28 GMT Etag: "f0276-906-8e70b300" Accept-Ranges: bytes Content-Length: 2310 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: image/gif ---------------------------------------------------------- Si volvemos a solicitar la misma página las peticiones realizadas son: http://redes.agrega.indra.es/ GET / HTTP/1.1 Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48 HTTP/1.x 301 Moved Permanently Date: Tue, 30 Sep 2008 08:12:36 GMT Server: Apache/2.0.52 (Red Hat) Location: http://redes.agrega.indra.es/visualizadorcontenidos/ Content-Length: 348 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html; charset=iso-8859-1 ---------------------------------------------------------- http://redes.agrega.indra.es/visualizadorcontenidos/ GET /visualizadorcontenidos/ HTTP/1.1

118

Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48 HTTP/1.x 302 Movido temporálmente Date: Tue, 30 Sep 2008 08:12:36 GMT Server: Apache/2.0.52 (Red Hat) X-Powered-By: Servlet 2.4; JBoss-4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)/Tomcat-5.5 Location: http://redes.agrega.indra.es/visualizadorcontenidos/Portada/Portada.do Content-Length: 0 Keep-Alive: timeout=15, max=99 Connection: Keep-Alive Content-Type: text/html;charset=ISO-8859-1 ---------------------------------------------------------- http://redes.agrega.indra.es/visualizadorcontenidos/Portada/Portada.do GET /visualizadorcontenidos/Portada/Portada.do HTTP/1.1 Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48 HTTP/1.x 200 OK Date: Tue, 30 Sep 2008 08:12:36 GMT Server: Apache/2.0.52 (Red Hat) X-Powered-By: Servlet 2.4; JBoss-4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)/Tomcat-5.5 Content-Language: es-ES Keep-Alive: timeout=15, max=98 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html;charset=ISO-8859-1 ---------------------------------------------------------- Apreciamos que al no haber cambiado los CSS ni las imágenes, no se han vuelto al descargar del servidor, el navegador tiene los CSS, imágenes y JS almacenados en la cache. Cuando descargamos un objeto, vemos que se devuelve la siguiente respuesta HTTP:

119

http://redes.agrega.indra.es/buscador/DescargarODECU/SeleccionarTipoFormatoAceptar.do?formato=descargar.formatos.SCORM_2004_VALUE&idioma=es&titulo=Clasifica+aparatos+y+Palabras+locas&identificadorODE=es_20071214_2_0102201&tipoLayoutBuscador=BUSCADOR GET /buscador/DescargarODECU/SeleccionarTipoFormatoAceptar.do?formato=descargar.formatos.SCORM_2004_VALUE&idioma=es&titulo=Clasifica+aparatos+y+Palabras+locas&identificadorODE=es_20071214_2_0102201&tipoLayoutBuscador=BUSCADOR HTTP/1.1 Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://redes.agrega.indra.es/buscador/DescargarODECU/DescargarODECU.do?identificadorODE=es_20071214_2_0102201&idioma=es&tipoLayoutBuscador=BUSCADOR&mostrarVuelta=true Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48 HTTP/1.x 302 Movido temporálmente Date: Tue, 30 Sep 2008 08:25:05 GMT Server: Apache/2.0.52 (Red Hat) X-Powered-By: Servlet 2.4; JBoss-4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)/Tomcat-5.5 content-disposition: attachment;filename=Clasifica_aparatos_y_Palabras_locas.zip Cache-Control: public Expires: Wed, 01 Oct 2008 08:25:09 GMT Location: http://redes.agrega.indra.es/repositorio/13062008/temp/SCORM_2004/Clasifica_aparatos_y_Palabras_locas.zip Content-Length: 0 Keep-Alive: timeout=15, max=99 Connection: Keep-Alive Content-Type: application/zip;charset=ISO-8859-1 ---------------------------------------------------------- http://redes.agrega.indra.es/repositorio/13062008/temp/SCORM_2004/Clasifica_aparatos_y_Palabras_locas.zip GET /repositorio/13062008/temp/SCORM_2004/Clasifica_aparatos_y_Palabras_locas.zip HTTP/1.1 Host: redes.agrega.indra.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://redes.agrega.indra.es/buscador/DescargarODECU/DescargarODECU.do?identificador

120

ODE=es_20071214_2_0102201&idioma=es&tipoLayoutBuscador=BUSCADOR&mostrarVuelta=true Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48 HTTP/1.x 200 OK Date: Tue, 30 Sep 2008 08:25:09 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Tue, 30 Sep 2008 08:25:08 GMT Etag: "39686b8-8728c-b8b26100" Accept-Ranges: bytes Content-Length: 553612 Keep-Alive: timeout=15, max=98 Connection: Keep-Alive Content-Type: application/zip ---------------------------------------------------------- Observamos que haciendo la petición el 30 de Septiembre de 2008 a las 08:25 GMT, se nos devuelve un objeto que caduca el día siguiente y cuya fecha de modificación ha sido el instante actual en el que se acaba de crear. Si solicitamos de nuevo el fichero habrá sido cacheado por las caches intermedias que existan y no se detectará cambio hasta el día siguiente. 3.3.1. Configuración Squid En función de número de conexiones simultáneas y descargas que tengamos en la CCAA, podría ser necesario habilitar SQUID como Proxy transparente cacheando los contenidos devueltos por el portal para evitar que las peticiones lleguen hasta Apache o incluso al propio JBossAS. Para ello, si se ha instalado Squid 3 el fichero de configuración es el siguiente: /etc/squid3/squid.conf Los parámetros más importantes son: http_port 3128 transparent Es el puerto por el que el proxy va a recibir las peticiones http de los clientes. El puerto por defecto para Squid es el 3128. La opción "transparent" es imprescindible si lo que queremos es que Squid actúe de forma transparente, esto es, sin tener que configurar el proxy en cada uno de los navegadores de los clientes. icp_port 3130 Puerto por el que Squid hace las consultas ICP (Internet Caché Protocol) a la caché. El puerto estándar UDP para ICP es el 3130. dns_nameservers 192.168.10.2 192.168.10.1 Servidores DNS que debe utilizar Squid. cache_dir ufs /var/spool/squid 100 16 256

121

Con este parámetro indicamos donde queremos que se almacene la caché de Squid.

• ufs: Es el tipo de almacenamiento donde se van a almacenar los datos. • 100: Tamaño máximo de la caché de Squid en MB. • 16: Número máximos de directorios en el nivel 1 del árbol de directorios de

la caché. • 256: Número máximo de directorios en el nivel 2 del árbol de directorios de

la caché.

Normalmente se almacena por defecto en /var/spool/squid3/. cache_access_log /var/log/squid3/access.log cache_log /var/log/squid3/cache.log cache_store_log /var/log/squid3/store.log Estos parámetros permiten especificar la ubicación de los logs de Squid. Por defecto están localizados en /var/log/squid3/. hierarchy_stoplist cgi-bin ? Este parámetro es útil cuando tenemos varias cachés interconectadas (hermanas, hijas,...). Las URL's que contengan las palabras o cadenas especificadas en este parámetro se irán a buscar directamente a la caché propia del servidor y no a otra de las cachés que pudiera haber. refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern . 0 20% 4320

• El primer valor (min) indica el tiempo mínimo con el cual un objeto se

considera reciente (fresh). • El segundo valor (percent) indica el porcentaje de la edad del objeto con el

que es considerado reciente (fresh). • El tercer valor (max) indica el tiempo máximo con el cual un objeto se

seguirá considerando reciente (fresh). acl all src 0.0.0.0/0.0.0.0 acl manager proto cache_object acl localhost src 127.0.0.1/255.255.255.255 acl to_localhost dst 127.0.0.0/8 acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT

122

acl mipc src 172.22.44.112/255.255.255.0

Las "acl" en Squid (Access Control List) sirven para definir controles de acceso de equipos, puertos, conexiones... La sintaxis es la siguiente: "acl nombre_acl tipo_acl descripción". También se pueden especificar mediante ficheros con la siguiente sintaxis: acl nombre_acl tipo_acl "fichero_de_descripciones" (por ejemplo un grupo de muchos equipos o redes). Tipos de acl:

• src: Especifica una dirección origen de una conexión en formato IP/máscara.

• dst: Específica una dirección destino de una conexión en formato IP/máscara.

• port: Sirve para especificar un puerto. • proto: Sirve para indicar un protocolo en concreto. • method: Especifica un método HTTP en concreto (POST CONNECT GET

REQUEST...). cache deny QUERY Indica que no se deben cachear las URL's del ACL indicado (en este caso el ACL se llama QUERY y puede estar declarada por ejemplo como "acl QUERY urlpath_regex cgi-bin \?"). http_access allow manager localhost http_access deny manager http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow localhost http_access allow all http_access allow mipc http_access deny all Sirve para permitir/denegar/administrar el acceso de las "acl" definidas anteriormente. http_reply_access allow all Se usa como complemento al parámetro "http_access" para refinar el control de acceso al Squid. icp_access allow all Permite establecer en las "acl's" los permisos para las peticiones ICP. 3.3.2. Configuración en el SO para las redirecciones Si deseamos redirigir el tráfico que llega desde una determinada interfaz de red por el puerto 80 al puerto de Squid, podemos con iptables ejecutar el siguiente

123

comando: /sbin/iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128 Redirigimos todas las peticiones que se reciben en el servidor en la interfaz eth0 por el puerto 80 al puerto 3128 que es configurado previamente en Squid. Podemos comprobar que se ha establecido correctamente la regla con: iptables -t nat -L Además debemos activar el reenvío de paquetes en el kernel. Esto lo hacemos mediante el siguiente comando: echo 1 > /proc/sys/net/ipv4/ip_forward Para comprobar que Squid está cacheando podemos ver que los directorios donde se ha establecido que se cachee (por defecto /var/spool/squid/) van aumentando de tamaño a medida que se navega a través del proxy.


¿Cómo puedes examinar los ficheros de configuración del servidor NFS?

¿Cómo puedes examinar los ficheros de configuración de MySQL o LDAP?

¿Qué comprobaciones son necesarias realizar en el sistema para que el servidor JBoss funcione correctamente?

¿Qué directorios propios de Agrega son necesarios dentro del directorio $JBOSS_HOME? ¿Cómo puedes comprobar su contenido?

¿Dónde se encuentran los archivos de configuración del JBoss y del portal Agrega? ¿Cuáles son y para qué sirven?

¿Dónde se encuentran almacenados los Wars del aplicativo?

Si se encuentra instalado Apache como servidor Web, ¿cuáles son los ficheros de configuración más importantes del Servidor Web Apache?

124


Manual módulo 4 Administración

125

Índice Contenido del módulo 4 Administración 1. Contenidos

1.1 . Noticias 1.2 . Descargas 1.3. Preguntas frecuentes

2. Plataforma

2.1. Nodo

2.2. Usuarios

2.3. Logs

2.4. Informes

2.5. Planificador

2.6. Modificador

2.7. Monitorizador

2.8. Grupos de usuarios

2.9. Taxonomías y Tesauros 3. Configuración 3.1. Publicador

3.2. Catalogador

126

Módulo 4. Administración


• Objetivos

- Analizar el módulo de administración de la plataforma Agrega.

- Identificar los distintos apartados del módulo de administración

- Lanzar tareas programadas desde la plataforma Agrega. - Gestionar usuarios desde la plataforma Agrega. - Consultar ficheros de log desde la interfaz de la

plataforma. - Gestionar los nodos federados con el nodo local. - Utilizar el procedimiento de generación de informes de

Agrega. - Manejar la funcionalidad general propia de un usuario

administrador.

• Contenidos

− Contenidos. − Plataforma. − Configuración.


127

1 h


Desde este apartado es posible llevar a cabo una planificación de tareas con el fin de ejecutarlas o administrarlas posteriormente en la plataforma (por ejemplo, una carga masiva de objetos digitales educativos, elaboración de noticias, etc.). Este apartado consta de tres módulos que veremos a continuación:

• Contenidos • Plataforma • Configuración

1. Contenidos Este módulo se compone de los siguientes apartados:

1.1. Noticias Pulsando sobre las noticias o seleccionándolas se accede a una pantalla con diferentes campos donde éstas se pueden modificar. Desde la pantalla principal de Noticias también se pueden crear nuevas noticias o eliminar las ya existentes. Los campos que componen el formulario de Noticias son: título, fecha, resumen, cuerpo, idioma, categoría, imagen y estado. A la hora de crear una noticia hay que tener en cuenta que todos estos campos son obligatorios excepto el campo Imagen.

128

1.2. Descargas Desde esta pantalla se pueden crear, modificar y eliminar las descargas. Éstas pueden estar activadas o no, apareciendo en la página principal de descargas solamente aquellas que están activas. Las descargas, por tanto, pueden estar:

• Activadas: en esta pantalla se muestran las descargas que se encuentran actualmente activas, con su título y fecha de creación. Pulsando en Desactivar, la descarga se desactiva, es decir, sigue existiendo pero no se muestra al usuario público.

• Desactivadas: en esta pantalla se muestran las descargas que se

encuentran actualmente no activas, con su título y fecha de creación. Pulsando en Activar, la descarga se activa.

Para crear/modificar una descarga es necesario configurar un título y una descripción en los idiomas deseados, así como indicar la ruta en el servidor del fichero que se desea servir por medio de las páginas de descargas. Si la ruta es válida, se copiará el fichero a una ruta propia de la herramienta. 1.2.1. Agrega off-line La plataforma Agrega incluye en su zona de descargas un paquete de herramientas disponible para descargar, instalar en el PC y utilizar sin necesidad de contar con una conexión a Internet. El paquete de herramientas incluye: empaquetador/catalogador, visualizador, validador y herramienta de modificación. Puedes descargarte el archivo de instalación de las herramientas Agrega en la zona de Descargas del portal. 1.2.2. Requisitos de la herramienta off-line El software que hace que las herramientas Agrega funcionen en el PC está basado en la tecnología Java J2EE. El uso de esta tecnología y las condiciones implícitas de las herramientas hacen que los requisitos para utilizar Agrega off-line sean los siguientes:

• Requisitos hardware:

- 200 MB de espacio libre en disco duro.

- 1 GB de memoria RAM.

• Requisitos software:

- Máquina virtual de Java (JRE) 1.5 o superior.

- Navegador Web (recomendados Internet Explorer 5+ y Firefox 2+).

129

1.2.3. Procedimiento de instalación Para instalar las herramientas Agrega, simplemente debes ejecutar el instalador y seguir las instrucciones que aparecen en la pantalla. Recuerda que debes instalar las herramientas en una carpeta cuyo nombre no tenga espacios, por ejemplo:

• C:\Aplicaciones\Agrega -> Correcto

• C:\Archivos de Programa\Agrega -> Error

1.2.4. Uso de las herramientas Para poder utilizar las herramientas Agrega en tu ordenador, ve al menú Inicio -> Programas -> Agrega, y ejecuta Iniciar Servidor. Este enlace iniciará la aplicación que contiene las herramientas. El proceso puede ser un poco lento dependiendo del equipo. El servidor estará listo para funcionar cuando aparezcan estos mensajes:

• 17:24:37,567 INFO [Catalina] Initialization processed in 1078 ms • 17:24:55,143 INFO [Catalina] Server startup in 17576 ms

Una vez se ha iniciado el servidor, ve a Inicio -> Programas -> Agrega, y ejecuta Herramientas–Agrega. Se abrirá entonces el navegador Web por defecto con la pantalla principal de las herramientas Agrega:

La pantalla principal contiene el menú que da acceso a las herramientas contenidas en el paquete. Las opciones disponibles son:

• Crear ODE: abre el empaquetador para iniciar la creación de un nuevo objeto digital educativo.

• Abrir ODE: permite editar con el empaquetador un objeto digital educativo

130

almacenado en tu ordenador. El objeto debe estar en formato comprimido.

• Visualizar ODE: permite visualizar los contenidos de un ODE en formato comprimido almacenado en tu ordenador.

• Validar ODE: pasa una validación de contenidos y metadatos a un ODE comprimido almacenado en tu ordenador. La validación garantiza que un ODE está listo para ser publicado en la plataforma Agrega (previa aprobación del publicador de la plataforma).

• Herramienta de modificación: permite crear y ejecutar tareas para la modificación y/o validación en bloque de múltiples ODEs.

• Configurar Datos de Usuario. Configura la aplicación para personalizar los siguientes parámetros:

- Datos personales de usuario: se usan para los datos automáticos de catalogación.

- Tipo de empaquetador/catalogador: permite elegir entre usar las herramientas avanzadas o básicas.

- Idioma: permite seleccionar el idioma en que desea usar las herramientas.

Las opciones Abrir, Visualizar y Validar ODEs solicitan al usuario que seleccione un ODE almacenado en el ordenador. Para asegurar que el objeto cumple los estándares necesarios para operar con las herramientas, el objeto en cuestión debe pasar una validación. En caso de que la validación no se supere, se muestra una pantalla con los errores encontrados. Para saber cómo usar las herramientas incluidas en el paquete de herramientas, ve a la sección correspondiente de la herramienta. 1.2.5. Problemas más comunes A continuación, se detallan dos de los problemas más comunes que pueden surgir durante la instalación o el uso del paquete de herramientas Agrega:

1. El script 'Iniciar servidor' no hace nada. Cuando intento abrir 'Herramientas Agrega' me aparece una pantalla de error. Necesitas tener una máquina virtual de Java instalada (JRE 1.5 o superior) y una variable de entorno apuntando a la carpeta donde está instalada, por ejemplo: C:\Archivos de programa\Java\jre1.6.0_06. La variable de entorno que debes crear depende de la máquina virtual de Java que tengas instalada. En caso de que sólo hayas instalado un entorno de ejecución (JRE), deberás configurar la variable JRE_HOME, apuntando a la carpeta correspondiente, por ejemplo: C:\Archivos de programa\Java\jre1.6.0_06. Si tienes el entorno de desarrollo (JDK), la variable a crear será JAVA_HOME, apuntando a la carpeta correspondiente, por ejemplo: C:\Archivos de programa\Java\jdk1.5.0_15.

131

Para configurar una variable de entorno en Windows, abre el Panel de control y selecciona Sistema. En la pestaña Opciones Avanzadas, pulsa Variables de entorno. Si no tienes ninguna variable JRE_HOME (o JAVA_HOME) creada, crea una con el directorio donde se encuentre instalada la JRE (o JDK) de Java.

2. El script 'Iniciar servidor abre una consola donde se muestra el mensaje de error 'java.net.BindException: Address already in use: JVM_Bind:8080'. Tienes una aplicación en tu PC que está escuchando en el puerto 8080 (p.ej., Apache Tomcat, Jboss, Sun One Server…). Apaga esta aplicación y vuelve a iniciar el servidor de herramientas Agrega.

1.3 . Preguntas frecuentes Al igual que ocurre en Noticias, desde esta pantalla se pueden administrar las preguntas frecuentes o FAQ´s. 1.3.1. Crear preguntas frecuentes Para crear una FAQ se pulsa sobre el botón Crear, apareciendo una pantalla con los distintos campos: pregunta, respuesta, idioma y categoría. Todos los campos son obligatorios excepto el idioma.

Al pulsar en Continuar, habrá que seleccionar la posición en la que se desea que aparezca la pregunta frecuente. 1.3.2. Modificar preguntas frecuentes Al pulsar sobre la pregunta o el botón Modificar aparecen los diferentes campos de que se compone el formulario de preguntas frecuentes.

Si se pulsa en Cancelar se vuelve a la pantalla anterior, y si se hace clic en Continuar se continúa el proceso de modificación seleccionando la posición en la que se desea que aparezca la pregunta frecuente modificada. Al pulsar el botón Aceptar se vuelve al listado de las preguntas frecuentes pero con la nueva ubicación. 1.3.3. Eliminar preguntas frecuentes Para eliminar una o varias preguntas frecuentes, basta con seleccionar la pregunta frecuente que se desee y pulsar sobre el botón Eliminar.


132

3 h


2. Plataforma Este módulo se compone de los siguientes apartados:

2.1. Nodo Se encarga de administrar los nodos que cada comunidad tiene para conectarse a la aplicación. En esta administración, se pueden crear nodos nuevos, y modificar y eliminar nodos ya existentes.

2.1.1. Crear nodo Para crear un Nodo se deben rellenar los siguientes campos:

• Nodo: es el nombre explicativo que se utiliza para reconocer el nodo.

• Url Nodo: es la url donde se encuentra el nodo.

• Url Web Service: es la url donde se encuentran los servicios a los que llama el nodo.

• Puerto: es el puerto por el que se comunica el nodo.

133

• Comunidad Autónoma: hay que elegir el nombre de la comunidad autónoma a la que corresponde el nodo.

Los tres primeros campos son obligatorios. Por otra parte, conviene recordar que la url del nodo y la url del Web Service suele ser la misma. Al pulsar sobre el botón Modificar, se pueden cambiar los datos de un nodo creado previamente. Para eliminar un nodo, se selecciona y se hace clic sobre el botón Eliminar. 2.2. Usuarios Se encarga de la gestión, creación y del mantenimiento de los usuarios de la aplicación. 2.2.1. Listar Usuarios

En esta pantalla (Listado) se listan todos los usuarios que existen en la aplicación. Desde aquí se puede crear un usuario nuevo, eliminar usuarios ya existentes, modificar usuarios y ver la descripción de cada usuario para conocer sus datos.

Los usuarios que aparecen en esta pantalla pueden exportarse a una hoja de Excel o a un documento en PDF a través de los enlaces que aparecen debajo del listado de usuarios. También se pueden ordenar los usuarios por orden alfabético (tanto ascendente como descendente) pinchando en la cabecera de la columna Usuarios.

Todos los usuarios pueden desactivarse (excepto el administrador) haciendo clic en Desactivar. Una vez desactivados, los usuarios pasarán a la lista Inactivos. 2.2.2. Crear usuario Al pulsar el botón Crear Usuario puedes dar de alta a un usuario. Para ello, tan sólo es necesario rellenar dos formularios: el primero se compone de los datos personales, datos de acceso y preferencias, y el segundo, con los grupos de usuarios a los que pertenece dicho usuario. Los campos marcados con asterisco (*) son obligatorios.Una vez que haya finalizado el proceso de alta de un usuario, se le enviará un e-mail al usuario con sus datos de acceso.

134

2.2.3. Modificar usuario Al pulsar sobre el botón Modificar, podrán modificarse todos los datos del usuario. Esta parte se compone de tres pantallas: la primera con los datos personales, datos de acceso y preferencias; una segunda pantalla con los grupos de usuario asignados al propio usuario, y la última pantalla que confirma que se han modificado los datos del usuario. Los campos NIF/Pasaporte/NIE y Usuario podrán modificarse, ya que son datos únicos del un usuario. 2.2.4. Descripción de usuario En esta pantalla se podrán ver los datos del usuario: datos personales, datos de acceso, preferencias y grupos. 2.2.5. Eliminar usuario La opción de eliminar usuarios (Eliminar) se compone de dos pantallas: una que confirma la eliminación de los usuarios seleccionados, y otra informando del resultado de la eliminación. Una vez finalizado el proceso de eliminación del usuario, se enviará un e-mail al usuario informándole de que ha sido dado de baja de la plataforma Agrega. 2.2.6. Listar usuarios inactivos En esta pantalla (Inactivos) se listan los usuarios que están inactivos. Desde el listado se pueden ver los detalles del usuario y activar uno en concreto. Al pulsar sobre Activar, aparecerá una ventana que confirme la operación. Si se prosigue con la operación, aparecerá otra ventana con el resultado de la activación. Si se produce algún error, aparecerá un mensaje que diga: “El usuario no se ha podido activar”. 2.3. Logs En esta pantalla se muestran los logs disponibles, que pueden verse o descargarse en caso de consulta. En el listado se muestra el nombre del log, con la fecha concatenada, y su tamaño. 2.4. Informes En esta pantalla aparece una lista con los informes generados a través de las tareas creadas desde el planificador. Los informes se pueden visualizar pulsando sobre su nombre, así como eliminar, seleccionándolos y pulsando en Eliminar. Para visualizar los informes en el momento de su generación (online), se puede hacer mediante el botón Generar informe.Los informes pueden ordenarse pinchando sobre la cabecera de la columna Informes.

135

2.4.1. Crear informes Esta aplicación (Crear informe) consta de dos pantallas: la primera, en la que indicaremos el informe que queremos visualizar; y una segunda pantalla que variará dependiendo del tipo de informe seleccionado. Los informes se dividen en tres tipos:

• Informe de Fechas. En este informe se especifican las fechas de inicio y fin, que indicarán la franja de la cual se tomarán los datos para realizar el informe. También se debe indicar el tipo de formato en el que se quiere mostrar el informe: HTML, Excel y Pdf.

• Informe de Rango. En este informe se especifican las fechas de inicio y fin, que indicarán la franja de la cual se tomarán los datos para realizar el informe. También se debe indicar el tipo de formato en el que se quiere mostrar el informe (HTML, Excel y Pdf) y el rango, que es el número de registros que se quieren ver en el informe.

• Informe de Usuario. En este informe se especifican las fechas de inicio y fin, que indicarán la franja de la cual se tomarán los datos para realizar el informe. También se debe indicar el tipo de formato en el que se quiere mostrar el informe (HTML, Excel y Pdf) y el usuario en concreto, ya que la información que se muestre en el informe hará referencia a un usuario en concreto.

El informe podrá visualizarse una vez que se elija el tipo de informe y se rellenen los datos correspondientes. A continuación, se detallan los distintos tipos de informe que existen:

• Estado de los contenidos digitales educativos. Este informe muestra los datos que hacen referencia a los contenidos digitales educativos de la aplicación, tales como el número de ODEs creados, publicados, etc.

• Operaciones realizadas. Este informe muestra una lista con las operaciones que se han realizado en la aplicación.

• Nivel de Agregación. Este informe muestra el número de ODEs que tienen asociado cada uno de los niveles de agregación.

• Cobertura curricular. Este informe muestra los contenidos digitales educativos que hay en cada uno de los nodos del árbol curricular.

• Términos más buscados. Este informe muestra cuáles han sido las palabras más buscadas en la aplicación.

• Informe de actividad de un usuario. Este informe muestra el estado de los contenidos digitales educativos y las operaciones que ha realizado el usuario con los ODEs.

• Licencias de los contenidos digitales educativos. Este informe muestra las diferentes licencias que existen en la plataforma y el número de ODES que tiene asignada cada licencia.

• Usuarios. Este informe muestra los diferentes usuarios que están dados de alta en la aplicación.

136

• Procesos ejecutados. Es este informe se listan las tareas planificadas de la aplicación y su estado.

• Contenidos digitales educativos más valorados. Este informe muestra cuáles son los contenidos digitales educativos más valorados por los usuarios de la aplicación.

• Contenidos digitales educativos más mostrados. Este informe muestra cuáles han sido los contenidos digitales educativos que más se han mostrado dentro de la aplicación.

• Contenidos digitales educativos más previsualizados. Este informe muestra cuáles han sido los contenidos digitales educativos que más se han previsualizado dentro de la aplicación.

• Contenidos digitales educativos más descargados. Este informe muestra cuáles han sido los contenidos digitales educativos que más se han descargado.

• Contenidos digitales educativos más grandes. Este informe muestra cuáles han sido los contenidos digitales educativos más grandes.

2.4.2. Eliminar informes Los informes se eliminan seleccionándolos con el check y pulsando sobre el botón Eliminar. 2.5. Planificador Este módulo se encarga de las tareas utilizadas para el mantenimiento del portal, tales como la carga de ODEs, reindexado, eliminar ODEs, generar tareas de informes, etc.

Esta pantalla se compone de tres pestañas: Pendientes, Ejecutándose y Ejecutadas. 2.5.1. Pendientes Muestra un listado con todas las tareas que están pendientes de ser ejecutadas o aquellas que habiéndose ejecutado tienen algún tipo de periodicidad.

137

Desde esta pantalla se puede ejecutar una tarea manualmente; en este caso la tarea permanecerá pendiente hasta que no se cumpla la fecha de ejecución. Las tareas pendientes se pueden modificar, pudiendo cambiar sólo algunos de sus campos, ejecutar manualmente y eliminar. La cabecera del listado de tareas se compone de:

• Tarea: es el nombre de la tarea. • Fecha: marca cuando se ejecutará nuevamente la tarea. • Periodicidad: puede ser diaria, semanal, mensual, anual, o no tener.

2.5.1.1. Crear tarea Las tareas se dividen en varios tipos: carga de ODEs pendientes, Reindexado, Eliminar ODEs… y una lista de informes que se pueden planificar. Esta pantalla es común para todos los tipos de tareas. En el proceso de creación cada tipo de tarea tendrá su propia pantalla.

En esta pantalla (Crear Tarea) todos los campos son obligatorios. Los campos que aparecen son:

• Nombre de Tarea: no están permitidos algunos caracteres como

#%&+"<>'. Además, el campo de texto tiene un máximo de 80 caracteres.

• Tipo de tarea: se puede seleccionar entre una lista.

• Fecha: se introduce la fecha exacta en que se ejecutará la tarea. El formato de la fecha es dd/mm/aaaa; y de la hora, hh/mm.

• Repetir: hace referencia a la periodicidad. Sus valores son: diaria, semanal, mensual, anual o no periódica. Marca si la tarea se ejecutará de nuevo (con la periodicidad seleccionada) o sólo se ejecutará en la fecha indicada (marcando la opción no periódica).

Todos los datos de la tarea pueden modificarse (Modificar) excepto el nombre y el tipo de la tarea, que no son modificables. Igualmente, en esta pantalla se puede acceder a una descripción con el fin de consultar los datos de la tarea. 2.5.1.2. Crear Tarea carga de ODEs Se trata de la segunda pantalla que aparece en el proceso de creación de la Tarea carga de ODEs. En ella deben introducirse tres urls:

138

• Carpeta ODEs: se indica dónde están los ODEs que se van a cargar. • Carpeta ODEs correctos: se indica dónde se van a guardar los ODEs

correctos. • Carpeta ODEs erróneos: se indica dónde se van a guardar los ODEs

incorrectos.

Los tres campos son obligatorios. Es importante saber que los nombres de los ODEs no deben tener ni acentos ni eñes. También es aconsejable que el nombre de los ODEs sólo contenga código ASCII. El usuario de JBOSS debe tener permisos de lectura y escritura en los tres directorios que se indican en las urls. Las tres urls pueden sufrir modificaciones (Modificar). 2.5.1.3. Crear Tarea reindexado Es la segunda pantalla del proceso de creación de la tarea de reindexado. Los ODEs se reindexarán en el idioma seleccionado.

El idioma del reindexado puede modificarse (Modificar). 2.5.1.4. Crear Tarea Eliminar ODEs Se trata de la segunda pantalla del proceso de creación de la tarea Eliminar ODEs. En ella deben introducirse (desde/hasta) las fechas en que se quieren eliminar los ODEs no disponibles. Ambas son obligatorias.

Podrán modificarse (Modificar) las fechas de inicio y fin de eliminación de los ODEs.

139

2.5.1.5. Crear Tarea Informe de fechas Es la segunda pantalla del proceso de creación de la tarea Informe de fechas. Deben especificarse las fechas de inicio y fin, que indicarán la franja de la cual se tomarán los datos para realizar el informe. También debe indicarse el tipo de formato en el que se quiere mostrar el informe: HTML, Excel y Pdf.

Podrán modificarse (Modificar) las fechas de inicio y fin de la tarea, así como el formato en que pretende mostrar el informe. 2.5.1.6. Crear Tarea Informe de rango Se trata de la segunda pantalla del proceso de creación de la tarea Informe de rango. En este informe deben especificarse las fechas de inicio y fin que indicarán la franja de la cual se tomarán los datos para realizar el informe. También deben indicarse el tipo de formato en el que se quiere mostrar el informe (HTML, Excel y Pdf) y el rango, que es el número de registros que se quieren mostrar en el informe, ya que los tipos de informe por rango serán del tipo los más.

Podrán modificarse (Modificar) todos los parámetros de esta pantalla. 2.5.1.7. Crear Tarea Informe de usuario Es la segunda pantalla del proceso de creación de la tarea Informe de usuario. En este informe deben especificarse las fechas de inicio y fin que indicarán la franja de la cual se tomarán los datos para realizar el informe. También deben indicarse el tipo de formato en el que se quiere mostrar el informe (HTML, Excel y Pdf) y el usuario en concreto, ya que la información que se muestre en el informe hará referencia a un usuario en concreto.

140

Podrán modificarse (Modificar) todos los parámetros de esta pantalla. 2.5.1.8. Eliminar Tarea Para eliminar una tarea, se selecciona la tarea que se quiere eliminar y se pulsa sobre el botón Eliminar. 2.5.1.9. Ejecutar Tarea Esta función se usa cuando el administrador quiere ejecutar una tarea manualmente. Para ello, se mantiene la tarea en el listado de Pendientes hasta su próxima ejecución en la fecha correspondiente. 2.5.2. Ejecutándose Muestra un listado con las tareas que se están ejecutando en ese momento. Si no hay ninguna tarea en ejecución también se indica. Las tareas en ejecución se pueden detener (Detener) pero no desaparecerán, quedando éstas registradas en Ejecutadas. 2.5.3. Ejecutadas Lista las tareas (trabajo) que se han ejecutado, mostrando la fecha en que se ha ejecutado la tarea y el estado que ha tomado ésta (correcto/error/interrumpido). Si una tarea se ejecuta de forma periódica, ésta aparecerá en el listado tantas veces como se haya ejecutado. Desde este listado las tareas también se pueden eliminar (Eliminar).

Desde el listado de tareas se puede consultar un informe (Ver informe) acerca del desarrollo de la tarea.

141

2.5.3.1. Informe Tarea Para las tareas de carga de ODEs se puede consultar un informe sobre el desarrollo de dicha tarea y ver si los ODEs se han cargado correctamente (correcto/error/interrumpido).

En Informe tarea aparecen los siguientes datos:

• Descripción: corresponde al tipo de tarea (carga de ODEs, reindexado…).

• Fecha de inicio y fin de la tarea (día/mes/año y hora). • Listado con los ODEs que se intentan cargar. • Estado de la carga de los ODEs (correcto/error/interrumpido).

2.5.3.2. Descripción Informe Tarea Muestra la descripción del intento de carga de un ODE en concreto, indicando el estado de su publicación. 2.6. Modificador El modificador o herramienta de modificación permite al administrador configurar tareas para la modificación en bloque de ODEs múltiples. Los cambios que la herramienta permite llevar a cabo en la catalogación de los ODEs serán de los siguientes tipos:

• Añadir Término LOM-ES: inserta un nuevo término en el metadato de cada ODE.

• Eliminar Término LOM-ES: elimina un término existente en el metadato. El término a eliminar se puede filtrar por valor y por idioma (si es traducible).

• Comprobar Término LOM-ES: comprueba la existencia de un término (opcionalmente se puede filtrar por valor y/o idioma).

• Modificar término LOM-ES: modifica el valor de un término del metadato.

• Validación.

Formato de XML para la configuración de tareas La herramienta proporciona un esquema XML para ayudar en la configuración de las tareas. La estructura básica de una tarea de modificación es la siguiente:

<?xml version="1.0" encoding="UTF-8"?>

<modification-task>

<changes>

...

</changes>

<objects>

142

...

</objects>

</modification-task>

El bloque changes engloba los cambios que se van a ejecutar sobre cada objeto. El bloque objects lista los objetos (carpetas de ODEs o localizaciones de ODEs individuales) que se van a modificar. Configuración de los cambios A continuación, se describe la configuración de los cambios permitidos por la herramienta de modificación:

• Añadir término LOM-ES Para configurar la adición de un nuevo término LOM-ES, se requiere el siguiente código:

<addition>

<lom-term>lom.technical.format</lom-term>

<new-value><![CDATA[<format>image/vnd.microsoft.icon</format>]]></new-

value>

<term-type>otro</term-type>

<main-lom-only>true</main-lom-only>

</addition>

La adición de un término LOM-ES requiere proporcionar cuatro parámetros: - Termino LOM-ES (lom-term): ruta XML del término LOM-ES que se desea

añadir. El formato para indicar la ruta son los nombres de las etiquetas separadas por puntos (desde la etiqueta principal lom hasta la etiqueta del término a añadir).

- Valor (new-value): código XML del término que se desea añadir. Recuerda que para incorporar código XML dentro de un XML debes encerrarlo en un bloque <![CDATA[...]]> o escapar los caracteres reservados.

- Tipo de término: (term-type): para la adición de nuevos términos se permite configurar la adición de nuevos árboles curriculares o tesauros como casos especiales. Esto permite insertarlos en el campo classification adecuado (purpose = discipline). Los valores disponibles para el tipo de termino son arbol-curricular, etb y otro.

- Alcance de metadatos (main-lom-only): Permite especificar si el cambio se realizara sobre el metadato principal del objeto (true) o sobre todos los metadatos encontrados en el manifiesto del objeto (false).

• Eliminación de término LOM-ES El código necesario para configurar la eliminación de un término LOM-ES es el siguiente:

143

<removal>

<lom-term>lom.rights.description.string</lom-term>

<value>aa</value>

<language>es</language>

<reg-exp>false</reg-exp>


</removal>

Los parámetros necesarios para configurar una eliminación son los mismos que para configurar una comprobación de término (Ver Comprobación de término LOM-ES).

• Comprobación de término LOM-ES Para configurar la comprobación de un termino LOM-ES se requiere este código:

<check>

<lom-term>lom.technical.duration.description.string</lom-term>

<value>.*duraci[oó]n.*</value>


<reg-exp>true</reg-exp>


</check>

El significado de los términos del código es el siguiente:

- Los campos lom-term y main-lom-only se configuran igual que en Añadir término LOM-ES.

- Valor (value, opcional): en el caso en que el término lom sea un término final, se puede comprobar la existencia de términos con un determinado valor (o rango de valores). Si se desea comprobar un rango de valores, este campo debe mostrar una expresión regular que comprenda el rango de valores buscados.

- Idioma (language, opcional): para aquellos términos LOM-ES que se pueden filtrar por idioma (por ejemplo lom.technical.duration.description.string) se permite especificar el idioma del término que se desea localizar. Si no se especifica un idioma, se mostrarán todos los términos encontrados con el valor especificado.

- Expresión regular (reg-exp): si se activa esta opción (<reg-exp>true</reg-exp>), se indica al sistema que el contenido de value debe ser interpretado como una expresión regular estándar de Java (Expresiones regulares en Java).

• Modificación de término LOM-ES El código necesario para configurar la modificación del valor de un término LOM-ES es el siguiente:

http://java.sun.com/javase/6/docs/api/java/util/regex/Pattern.html

http://java.sun.com/javase/6/docs/api/java/util/regex/Pattern.html

144

<modification>


<value>application/document</value>

<new-value>application/msword</new-value>


<replace-all>true</replace-all>


</modification>


- Los parámetros lom-term, value, language, reg-exp y main-lom-only se configuran igual que en los casos anteriores. En este caso, el término LOM-ES debe ser final, ya que el objetivo de la modificación es reemplazar el valor de un término por otro.

- Nuevo valor (new-value): nuevo valor que se asignará al término LOM-ES configurado.

- Reemplazo total (replace-all): si se le asigna el valor true, reemplaza el valor de todos los términos encontrados que cumplan esa condición; en caso contrario (false), solo se reemplaza el primer término encontrado.

• Validación de los objetos educativos La validación de objetos se configura de la siguiente manera:

<validation/>

La validación de objetos no requiere argumento ni configuración adicional. Configuración de los objetos El bloque objects permite definir las rutas que servirán para buscar los ODEs que van a ser modificados por esta tarea. Un ejemplo de configuración es:

<objects>

<folder>

<path>carpeta1/carpeta2</path>

</folder>

<ode>

<published>false</published>

<path>carpeta1/carpeta2/ode1.zip</path>

</ode>

<ode>

<published>true</published>

<path>carpeta1/carpeta2/ode</path>

</objects>

145


• El elemento folder permite definir una carpeta en la que buscar un conjunto de objetos no publicados. El sistema buscará, en tiempo de ejecución de la tarea, objetos (comprimidos en ZIP o descomprimidos en una carpeta) contenidos en la carpeta configurada a primer nivel (no se examinan las subcarpetas de forma recursiva).

• El elemento ode permite definir un objeto individual proporcionando la ruta al objeto (path) e indicando si se trata de un objeto publicado en el repositorio o no (published). Los objetos publicados son reindexados por el sistema en caso de que el objeto modificado pase una validación exitosa. Si la reindexación falla, la tarea de modificación restaura automáticamente el objeto original y la tarea se da por fallida.

Ejemplo de tarea El siguiente código muestra un ejemplo completo de la configuración de una tarea:

<?xml version="1.0" encoding="UTF-8"?>

<modification-task>

<changes>

<check>

<lom-term>lom.technical.duration.description.string</lom-term>

<value>image/gif</value>

<language>en</language>



</check>

<modification>


<value>image/gif</value>

<new-value>application/msword</new-value>


<replace-all>true</replace-all>


</modification>

<removal>

<lom-term>lom.rights.description.string</lom-term>

<value>.*duraci[oó]n.*</value>


<reg-exp>true</reg-exp>


146

</removal>

</changes>

<objects>

<folder>

<path>carpeta1/carpeta2</path>

</folder>

</objects>

</modification-task>

A continuación se detallan las distintas funcionalidades de la herramienta Modificador. 2.6.1. Pendientes La pantalla inicial del modificador muestra un listado con las tareas configuradas (no ejecutadas):

Las funcionalidades disponibles en esta pantalla son:

• Crear Tarea: inicia la creación de una nueva tarea de modificación.

• Importar Tarea: permite importar a la herramienta una tarea que ha sido definida de forma externa en un XML.

• Eliminar: elimina la tarea configurada y todos los ficheros del servidor asociados a la tarea.

• Modificar: abre el editor de tareas para modificar una tarea existente.

• Exportar: descarga al sistema de ficheros local del usuario el fichero de configuración de la tarea (ver Importar Tarea).

• Planificada/Sin Planificar: permite programar la ejecución de la tarea para una fecha y hora determinadas. Cuando se alcanza la fecha programada, el sistema lanza la ejecución de la tarea (del mismo modo que si el usuario pincha en Ejecutar).

• Ejecutar: ejecuta la tarea, anulando la planificación si la hubiera.

2.6.1.1. Crear Tarea La creación de una tarea de modificación se compone de varios pasos. El primero de ellos consiste en dar un nombre descriptivo a la tarea. En caso de estar modificando una tarea ya existente, el título de la cabecera de la pantalla será Modificar Tarea.

147

Una vez que se ha introducido el nombre de la tarea se pulsa en Continuar. Aparece entonces una pantalla con los elementos configurables en una tarea de configuración: Cambios y Objetos. Los cambios son operaciones sencillas a aplicar sobre cada objeto (ODE), como pueden ser modificaciones de uno o varios términos LOM-ES, validaciones, comprobaciones, etc. Los objetos son las localizaciones donde se encuentran los ODEs que se desean modificar. Se configuran las localizaciones, ya que los objetos se identifican en el momento de ejecutar la tarea. Donde la funcionalidad disponible es la siguiente:

Añadir Cambio: realiza la configuración de un nuevo cambio para la tarea de modificación.

Eliminar (en Cambios y Objetos): elimina el elemento seleccionado de la configuración de la tarea.

Volver: vuelve al paso anterior de la creación de la tarea.

Cancelar: cancela la creación de la tarea.

Guardar: acepta la configuración de la tarea y genera el fichero de configuración en el servidor. A continuación se muestra la pantalla de Simulación de tarea:

Al guardar una tarea de modificación se ofrece la posibilidad de simular la tarea. La simulación consiste en lanzar una ejecución de la tarea sobre un número reducido de ODEs (3) escogidos de forma aleatoria entre los configurados para modificar. Cuando la simulación finaliza, se muestra una pantalla de informe como la que se muestra para las tareas ejecutadas. 2.6.1.2. Importar Tarea La opción Importar tarea permite configurar una tarea en el nodo a partir de un fichero XML. Para ello basta con seleccionar el fichero XML del sistema local y pulsar en Aceptar. A continuación, la aplicación pregunta por el nombre que se desea para la tarea y se muestra la pantalla de edición de tareas (ver Crear Tarea). 2.6.1.3. Añadir cambio El botón Añadir Cambio, en la pantalla de configuración de tareas, sirve para realizar un cambio individual con el fin de aplicarlo sobre el conjunto de los ODEs de la tarea. Esta operación está compuesta de varios pasos, dependientes del tipo de cambio que se desea configurar.

148

En esta pantalla se selecciona el tipo de cambio u operación que se desea configurar. En el caso de seleccionar Validación, la configuración de la tarea finaliza, ya que este tipo de operación no necesita de más información. 2.6.1.4. Seleccionar término LOM-ES Si se selecciona como tipo de cambio Eliminar término LOM-ES, Comprobar término LOM-ES, Modificar término LOM-ES o Añadir término LOM-ES (exceptuando los tipos árbol curricular y etb), aparece una pantalla para seleccionar el término LOM-ES. Para ello, deben seleccionarse las etiquetas dispuestas en la tabla hasta componer la ruta LOM-ES del término que se desea cambiar. Una vez que en la barra superior aparece seleccionada la rama deseada, hay que pulsar sobre Seleccionar. El botón Seleccionar sólo aparece disponible cuando la rama seleccionada puede cambiarse con el tipo de cambio seleccionado. Tras seleccionar el término LOM-ES, se mostrará un formulario específico del cambio seleccionado. 2.6.1.5. Eliminar término El formulario para la eliminación de términos LOM-ES permite configurar los siguientes campos:

• Valor: si se desea eliminar un término con un valor determinado, este campo permite establecer el valor. Si se deja vacío, se eliminarán todos los términos encontrados.

• Expresión regular: activando este campo se comunica a la tarea que el campo Valor debe ser interpretado como una expresión regular de Java, pudiendo filtrar todos los términos cuyo valor se ajuste al rango de valores especificado por la expresión regular.

• Idioma: en el caso en que el término LOM-ES seleccionado sea de tipo LangString (término traducible), este campo permite seleccionar el idioma (en código ISO de dos letras) del término que se desea eliminar. Si se deja vacío, se eliminaran los términos independientemente del idioma.

• Alcance Metadatos: este campo permite establecer si el cambio debe efectuarse sólo en el metadato principal del ODE o en todos los metadatos contenidos en el manifiesto.

2.6.1.6. Comprobar término El formulario para la operación Comprobar término LOM-ES es idéntico al de Eliminar Término que acabamos de ver. Si no se establece un Valor, se informa de todos los términos encontrados independientemente de su valor o contenido. Lo mismo ocurre para el campo idioma. 2.6.1.7. Modificar término Los campos Valor, Expresión Regular e Idioma establecen el filtro de búsqueda del término cuyo valor se desea modificar. El comportamiento es el mismo que para Comprobar término o Eliminar término. Del mismo modo ocurre con el campo

149

Alcance metadatos. Los campos específicos del cambio Modificar término son:

• Nuevo valor: establece el nuevo valor para el término LOM-ES. En caso de que el término LOM-ES tenga un vocabulario controlado, se nuestra un combo seleccionable con las opciones, en lugar de un campo de texto libre.

• Alcance términos: permite especificar si se desean reemplazar todos los términos encontrados (del tipo especificado y con el valor e idioma introducidos en el formulario), o sólo el primero.

2.6.1.8. Añadir término (selección del tipo término) El campo Alcance metadatos se comporta igual que en casos anteriores. El campo Tipo permite especificar si el término que se desea añadir es una rama de árbol curricular o de tesauro, o cualquier otro término. Si se selecciona Otro, se pasa a la pantalla de selección de término LOM-ES y, a continuación, se presenta un formulario específico para añadir un término LOM-ES. 2.6.1.9. Añadir término (otro) Para añadir un término LOM-ES es necesario introducir el código XML del término que se desea insertar. En el formulario se ofrece una plantilla del término seleccionado, que tan sólo es necesario modificar para establecer los valores deseados. Si una etiqueta tiene un conjunto de valores posibles (<value>, en el ejemplo de la figura de arriba), se muestran todas las opciones posibles separadas por una barra “|“. Debe elegirse la opción correcta y descartar las demás. En el ejemplo de la figura, si seleccionamos family, el resultado será:

• <value>family</value>

2.6.1.10. Añadir término (árbol curricular) Para insertar un árbol curricular en el ODE basta con seleccionar la rama deseada en la pantalla de navegación del árbol curricular. Una vez seleccionada, el cambio para añadir el término queda seleccionado.

150

2.6.1.11. Añadir término (ETB) Al igual que en el caso del árbol curricular, para añadir una rama del tesauro o ETB basta con navegar en el árbol del tesauro hasta seleccionar la rama deseada. 2.6.1.12. Añadir objeto Al pulsar Añadir Objeto, desde la pantalla de configuración de tareas, aparece la pantalla de selección del tipo de objeto. Hay dos opciones posibles:

• Introducir ruta de los objetos: permite especificar una carpeta en el servidor donde previamente se han subido los objetos que se desean modificar.

• Buscar objetos: permite usar el buscador para seleccionar ODEs publicados en el repositorio.

2.6.1.13. Introducir ruta de los objetos El formulario muestra un campo de texto donde debe introducirse la ruta del servidor donde se encuentren los objetos previamente subidos por el administrador. Recuerde que los objetos subidos deben tener permisos de lectura/escritura para la plataforma (consultar administrador). 2.6.1.14. Buscar objetos La pantalla de búsqueda de objetos permite introducir criterios básicos de búsqueda para seleccionar objetos del repositorio. Estos criterios son:

• Identificador: permite buscar un rango de identificadores (permite

151

realizar una búsqueda con comodines).

• Título: realiza la búsqueda por palabras en el título del ODE (comodines permitidos).

• Autor: realiza la búsqueda por el nombre del autor.

• Fecha de publicación: busca los ODEs publicados en el rango de fechas especificado.

Una vez que se lanza la búsqueda se muestra un listado con los ODEs que coinciden con los criterios de búsqueda. Sobre el listado, se pueden seleccionar los ODEs conjuntamente (Seleccionar todos) o bien de manera individual (seleccionar el/los ODE/s y pulsar en Seleccionar). Una vez que se han seleccionado los ODEs, aparece una pantalla como ésta:

Para aceptar los ODEs seleccionados, se pulsa sobre Añadir. 2.6.2. Ejecutándose En la tabla se mostrarán los títulos de las tareas que se encuentran en ejecución en ese momento. Esta pantalla no ofrece ningún tipo de funcionalidad sobre estas tareas. 2.6.3. Ejecutadas En esta pantalla se muestra un listado con las tareas que se han ejecutado y con el resultado obtenido. Los resultados posibles son:

• Correcto: la tarea ha finalizado correctamente y los cambios se han aplicado a todos los ODEs originales.

152

• Revisar: la tarea ha finalizado sin errores, pero la herramienta recomienda revisar las trazas de todos o alguno de los ODEs.

• Error: la tarea no se ha ejecutado correctamente. Esto significa que alguno de los ODEs (o todos) no se han modificado correctamente y, por tanto, los cambios no se han aplicado a los ODEs. Los ODEs que se hayan modificado correctamente pueden ser restaurados desde la pantalla de informes.

La funcionalidad disponible en esta pantalla es la siguiente:

• Eliminar: elimina las tareas seleccionadas y los ficheros del servidor asociados. Conviene recordar que tras la eliminación de una tarea ejecutada no será posible restaurar ningún ODE modificado por dicha tarea. Por tanto, hay que asegurarse de que se está conforme con los cambios aplicados antes de eliminar la tarea.

• Ver Informe: muestra el listado de los ODEs que han sido modificados por la tarea y los resultados individuales para cada ODE.

2.6.3.1. Informe de Tarea Al pulsar sobre Ver Informe, desde la pantalla tareas Ejecutadas, se muestra un listado con los ODEs modificados por dicha tarea. En la cabecera de la pantalla se muestra el nombre de la tarea y el resultado global, con un mensaje descriptivo del mismo. Por cada ODE se muestra:

• Identificador del ODE.

• Resultado de la modificación sobre ese ODE (Correcto/Revisar/Restaurado/Error).

• Un enlace que muestra más información sobre la modificación del ODE, abriéndose una ventana con las trazas de los cambios disponibles en el servidor.

• Un enlace para deshacer los cambios (disponible en el estado de Correcto). Este enlace no está presente si la modificación ejecutada no ha supuesto cambios sobre el ODE (Validación y comprobación) o si realmente no se ha realizado (operación simulada).

2.6.3.2. Informe de ODE Al pulsar en Más Información, desde la pantalla del resultado de la tarea, se muestra la traza con los cambios realizados en el ODE seleccionado. Dicha traza muestra el resultado final del ODE y los mensajes de log correspondientes a la tarea de modificación sobre el ODE seleccionado. En el caso de los ODEs publicados, la republicación del ODE es posterior al cierre del fichero de traza. Esto significa que si ha habido un fallo en la republicación éste no se muestra en la traza, sino en el estado de la tarea. 2.7. Monitorizador

153

Indica el estado de los diferentes nodos que componen la aplicación, así como el estado de los diferentes servicios de cada nodo: Buscar, Entregar y Validar.

2.8. Grupo de usuarios Se encarga de la gestión, de la creación y del mantenimiento de los grupos de usuarios de la aplicación. Cada uno de estos grupos está compuesto por diferentes roles que son los que definen los permisos de los usuarios. 2.8.1. Listar grupos Se listan todos los grupos creados en la aplicación. Desde esta pantalla se puede crear un grupo nuevo, eliminar grupos ya existentes, modificar grupos y ver la descripción de cada uno de ellos.

Los grupos que aparecen en esta pantalla pueden ser exportados a un documento Excel o PDF, a través de los enlaces que hay debajo del listado de grupos. El listado también permite la ordenación de los grupos por orden alfabético (tanto ascendente como descendente) pinchando en la cabecera de la columna Grupos. 2.8.2. Crear grupo Desde esta pantalla se puede dar de alta a un grupo. Para ello se deben rellenar dos pantallas: la primera con el nombre del grupo, y la segunda con los permisos disponibles en la plataforma. 2.8.3. Modificar grupo Permite modificar los datos de grupo. Al igual que en Crear grupo, deben rellenarse dos pantallas: la primera con el nombre del grupo, y la segunda con los permisos que pueden tener los grupos de usuarios. 2.8.4. Descripción grupo En esta pantalla podrán verse los datos de un grupo, tanto el nombre como los permisos asociados a dicho grupo. 2.8.5. Eliminar grupo Cuando se elimina un grupo, aparecen dos pantallas: la primera de confirmación,

154

en la que debemos verificar que queremos eliminar dichos grupos; y una segunda pantalla de información, que contiene los grupos que han sido borrados o eliminados de la aplicación. 2.9. Taxonomías y Tesauros Permite administrar las diferentes estructuras admitidas por la plataforma: árboles curriculares, taxonomías y tesauros. 2.9.1. Árbol curricular Para añadir un nuevo árbol curricular a la aplicación, los requisitos que debe cumplir dicho archivo son:

• Ser un archivo XML con formato VDEX, es decir, un estándar que define una gramática necesaria para el intercambio de listas de valores, denotadas como vocabularios. VDEX se utiliza, por tanto, para normalizar las taxonomías y tesauros introducidos en Agrega, de forma que la plataforma sea capaz de interpretarlos de forma análoga.

• Debe validar contra el VDEX de árbol curricular. • El nombre del fichero debe acabar en _idioma, donde el idioma debe ser un

código ISO, por ejemplo: _en (inglés); _es (español); _ca (catalán); _eu (euskera), etc.

Para añadir un nuevo árbol curricular se pulsa en Añadir árbol y se selecciona el fichero que se desea subir. Una vez realizada la acción, el árbol curricular que se encuentre en esta pestaña será el árbol curricular vigente para el nodo donde se haya realizado el cambio. Al subir un nuevo árbol curricular, el antiguo árbol curricular que coincida con el idioma del nuevo árbol se cambia automáticamente al listado de taxonomías. En este caso se podrá eliminar cualquier árbol curricular, excepto el que esté en castellano. Para ello habrá que seleccionar el árbol que se quiere borrar y pulsar sobre el botón Eliminar. 2.9.2. Taxonomía Para añadir una nueva taxonomía, los requisitos que debe cumplir dicho archivo son:

• Ser un archivo un XML con formato VDEX, es decir, un estándar que define una gramática necesaria para el intercambio de listas de valores, denotadas como vocabularios. VDEX se utiliza, por tanto, para normalizar las taxonomías y tesauros introducidos en Agrega, de forma que la plataforma sea capaz de interpretarlos de forma análoga.

• Debe validar contra el VDEX de taxonomía.

• El nombre del fichero debe acabar en _idioma, donde el idioma debe ser un código ISO, por ejemplo: _en (inglés); _es (español); _ca (catalán); _eu (euskera), etc.

155

Para añadir la nueva taxonomía hay que pulsar en Añadir taxonomía y seleccionar el fichero que se desea subir. Todas las taxonomías que se encuentren en esta pestaña estarán disponibles en el catalogador avanzado, en la categoría de Clasificación, siendo posible seleccionarlas con el fin de navegar por ellas y recoger una ruta de taxones para los metadatos. En este caso es posible eliminar cualquier taxonomía, seleccionándola y pulsando en el botón Eliminar. 2.9.3. Tesauro Para añadir un nuevo tesauro los requisitos que debe cumplir dicho archivo son:

• Ser un archivo XML con formato VDEX, es decir, un estándar que define una gramática necesaria para el intercambio de listas de valores, denotadas como vocabularios. VDEX se utiliza, por tanto, para normalizar las taxonomías y tesauros introducidos en Agrega, de forma que la plataforma sea capaz de interpretarlos de forma análoga.

• Debe validar contra el VDEX de tesauro.

• El nombre del fichero debe acabar en _idioma, donde el idioma debe ser un código ISO, por ejemplo: _en (inglés); _es (español); _ca (catalán); _eu (euskera), etc.

Para añadir un nuevo tesauro hay que pulsar en Añadir tesauro y seleccionar el fichero que se desea subir. A partir de este momento, el tesauro ETB que se encuentra en esta pestaña será el tesauro ETB vigente para el nodo donde se haya realizado el cambio. En este caso es posible eliminar cualquier tesauro, excepto el que está en idioma castellano. Para ello habrá que seleccionar el tesauro que se quiere borrar y pulsar sobre el botón Eliminar.


30 min


3. Configuración Este módulo se compone de los siguientes apartados:

3.1. Publicador Esta aplicación se encarga de administrar los ODEs publicados y los despublicados. Desde esta pantalla se tiene acceso a los ODEs que los usuarios han propuesto para

156

publicar y a aquellos que están despublicados. Los ODEs publicados se pueden rechazar o publicar; mientras que los ODEs despublicados se pueden eliminar o volver a publicar. También se puede acceder al historial del ODE. Para publicar un ODE es necesario ser un usuario con rol de publicador. La pantalla que aparece por defecto es la de los objetos pendientes de publicación. Esta pantalla muestra todos los objetos propuestos por los usuarios para su publicación una vez que han pasado la fase de catalogación. El enlace del título del ODE permite acceder a su previsualización. 3.1.1. Rechazar Un ODE se puede rechazar, pero para ello es obligatorio introducir un comentario. En el historial del ODE aparecerá reflejado el usuario que ha realizado la operación, el comentario y la fecha. El ODE aparecerá en la pestaña de ODEs creados. 3.1.2. Publicar Un ODE se puede publicar tanto desde la pestaña de objetos pendientes como desde la de objetos despublicados, pero para ello es obligatorio introducir un comentario. En el historial del ODE aparecerá reflejado el usuario que ha realizado la operación, el comentario y la fecha. Si el ODE se ha publicado correctamente se volverá a la pestaña desde la que se accedió (Pendientes o Despublicados). El ODE aparecerá en la pestaña de ODEs publicados. Para publicar un ODE es necesario indicar la licencia que se le aplica y el ámbito en el que el ODE va a ser visible. Si lo que se desea es modificar la licencia y el ámbito, se accederá a la siguiente pantalla:

157

La licencia se escoge de un desplegable con todas las licencias contempladas en la plataforma. Por su parte, el ámbito se selecciona de la lista de nodos con los que la plataforma Agrega está federada. En caso de seleccionar todos los nodos, el ámbito será universal. 3.1.3. Despublicados En esta pantalla se muestran todos los objetos que han sido despublicados en la plataforma, además eliminar, publicar, modificar o ver el historial de los mismos. También se puede acceder a una previsualización mediante el enlace del título.

Para modificar el contenido de un ODE despublicado, hay que tener el rol de empaquetador.

La publicación de un ODE despublicado se realiza de la misma forma que la de un ODE en estado pendiente para publicación. 3.2. Catalogador Esta aplicación se encarga de administrar los ODES pendientes de la catalogación. Los ODEs se pueden proponer para su publicación o modificación. También se puede acceder al historial del ODE desde esta pantalla. Para publicar un ODE, hay que tener el rol de publicador; y para modificarlo (Modificar), el de empaquetador. Se accede al módulo de empaquetador (dependiendo de si el usuario es avanzado o básico) con el ODE seleccionado para poder llevar a cabo las modificaciones que se consideren oportunas Al pinchar sobre el enlace del ODE, se accede a una previsualización del mismo. 3.2.1. Proponer Significa que el ODE se propone para su publicación. Es obligatorio añadir un comentario a esta pantalla. 3.2.2. Ver historial Aparece la misma pantalla que cuando accedemos a ella desde el publicador (Ver Publicador).


Crea una noticia completando los campos que aparecen en el formulario. Si lo deseas, puedes incluir una imagen que acompañe al texto.

158

Crea una pregunta frecuente o FAQ con su correspondiente respuesta.

Elabora un informe que muestre cuáles son los contenidos digitales educativos que más veces se han previsualizado dentro de la aplicación.

159


Manual módulo 5 Operación

160

Índice Contenido del módulo 5 Operación y mantenimiento de la plataforma 1. Arranque y parada de los aplicativos

1.1. JBoss 1.2. Servidor Web Apache 1.3. MySQL 1.4. LDAP 1.5. Servidor NFS

2. Ficheros de Log 2.1. JBoss 2.2. Apache 2.3. MySQL 2.4. LDAP 3. Backups 3.1. Bases de datos 3.2. OpenLDAP 4. Modificaciones frente a cambios frecuentes

4.1. Modificación de la base de datos del portal Agrega 4.2. Modificación de la base de datos 4.3. Cambio de datos de conexión de LADP 4.4. Cambio de IP del JBoss 4.5. Cambio del IP de Apache

5. Tareas planificadas

5.1. Parámetros de configuración del planificador 5.2. Tareas

6. Generación automática de ficheros

6.1. Generación de los informes de portada 6.2. Generación de ficheros sitemap 6.3. Generación del contenido dinámico de la plataforma 6.4. Generación del catálogo 6.5. Generación de rss

7. Seguridad

7.1. Seguridad en JBoss 7.2. Seguridad en Apache

8. Actualización MediaWiki

161

Módulo 5. Operación


• Objetivos

- Analizar el modo de operación de la plataforma Agrega. - Llevar a cabo el mantenimiento del nodo. - Utilizar los comandos y ficheros para operar con los distintos

componentes de Agrega. - Identificar posibles problemas ocurridos en los componentes. - Buscar los ficheros de log de los componentes de la plataforma. - Identificar aquellos elementos de los cuales es conveniente tener un

backup. - Utilizar los ficheros a modificar frente a las modificaciones

frecuentes que suelen ocurrir en los entornos de producción. - Identificar las tareas planificadas que se ejecutan cada cierto

tiempo en la plataforma.

• Contenidos

− Arranque y parada de los aplicativos. − Ficheros de Log. − Backups. − Modificaciones frente a cambios frecuentes. − Tareas planificadas. − Generación automática de ficheros. − Seguridad. − Actualización MediaWiki.


162

1 h


Asumiendo la instalación de la plataforma Agrega en sistemas operativos Linux, vamos a ver los comandos, ficheros, logs… necesarios para la operación y mantenimiento de la plataforma. 1. Arranque y parada de los aplicativos En el directorio /etc/init.d/ se encuentran todos los “scripts” que facilitan el arranque y la parada de los servicios. Estos “scripts” comúnmente aceptan como argumentos "start", "start" y "restart”. 1.1. JBoss Arranque: /etc/init.d/jboss start Parada: /etc/init.d/jboss stop Para comprobar si se encuentra el JBoss arrancado podemos ejecutar el comando: ps auxww | grep –i java Obteniéndose una salida similar a la siguiente: jboss 13135 0.6 29.8 2707440 760348 ? Sl Sep29 6:24 /opt/jdk/bin/java -Dprogram.name=run.sh -server -Xmn100M -Xms512M -Xmx1536M -XX:MaxPermSize=786M -Djava.awt.headless=true -Djava.endorsed.dirs=/opt/jboss-redes/lib/endorsed -classpath /opt/jboss-redes/bin/run.jar:/opt/jdk/lib/tools.jar org.jboss.Main -c default -b 0.0.0.0 Es importante destacar que en el script de arranque de init.d de JBoss se encuentren presentes los siguientes parámetros:

• -c default - Especificamos que la configuración a usar sea la default, por lo que se

accederá a $JBOSS_HOME/server/default/deploy. - En casos de clustering de JBoss se recomienda arrancar con “all” en

lugar de “default”. • -b 0.0.0.0

- Especificamos que JBoss haga bind en todas las interfaces de red. En cada CCAA dicho parámetro podrá ser ajustado para que JBoss únicamente escuche en la red por la que provienen las conexiones de Apache.

Después de ejecutar el comando de stop, cuando realmente finalice el servicio podremos apreciar en los logs del servidor JBoss la siguiente traza: 2008-09-29 19:54:06,452 INFO [org.jboss.system.server.Server] Shutdown complete

163

1.1.1. Eliminación despliegues anteriores Si vamos a actualizar la versión de Agrega, es conveniente limpiar previamente todos los despliegues anteriores (tanto clases como JSPs) mediante los siguientes pasos:

• Paramos el servidor de aplicaciones JBoss. • Borramos el contenido del directorio:

$JBOSS_HOME/server/default/tmp/deploy/ • Borramos el contenido del directorio:

$JBOSS_HOME/server/default/work/jboss.web/localhost/ • Desplegamos los nuevos WARS, properties, etc. • Arrancamos el servidor de aplicaciones JBoss.

1.2. Servidor Web Apache Arranque: /etc/init.d/httpd start Parada: /etc/init.d/httpd stop Recarga en caliente de la configuración sin pérdida de servicio: /etc/init.d/httpd graceful Para comprobar si se encuentra Apache arrancado podemos ejecutar el comando: ps auxww | grep –i httpd Obteniéndose una salida similar a la siguiente: apache 28745 0.0 0.9 28780 9368 ? S 09:54 0:00 /usr/sbin/httpd apache 849 0.0 1.7 36688 18288 ? S 10:54 0:00 /usr/sbin/httpd … 1.3. MySQL Arranque: /etc/init.d/mysql start Parada: /etc/init.d/mysql stop Para comprobar si se encuentra el servicio de base de datos MySQL arrancado podemos ejecutar el comando: ps auxww | grep –i mysqld Obteniéndose una salida similar a la siguiente: mysql 2754 2.5 11.9 2412144 311028 ? Sl Sep29 24:31 /usr/sbin/mysqld --basedir=/ --datadir=/var/lib/mysql --user=mysql --pid-file=/var/lib/mysql/database.agrega.indra.es.pid --skip-external-locking --port=3306 --socket=/var/lib/mysql/mysql.sock

164

1.4. LDAP Arranque: /etc/init.d/ldap start Parada: /etc/init.d/ldap stop Para comprobar si se encuentra el servicio de directorio LDAP arrancado podemos ejecutar el comando: ps auxww | grep –i slapd Obteniéndose una salida similar a la siguiente: ldap 29512 0.0 0.3 27660 3736 ? Ssl Sep28 0:00 /usr/sbin/slapd -u ldap -h ldap:/// -s 9 1.5. Servidor NFS Arranque: /etc/init.d/nfs start Parada: /etc/init.d/nfs stop Para comprobar si se encuentra el servicio de exportación NFS arrancado podemos ejecutar el comando: ps auxww | grep –i nfsd Obteniéndose una salida similar a la siguiente: root 2925 0.1 0.0 0 0 ? S Mar04 350:01 [nfsd] root 2926 0.1 0.0 0 0 ? S Mar04 349:45 [nfsd]


1 h


2. Ficheros de Log La ubicación de todos los ficheros de log son configurables desde sus respectivos ficheros de configuración que ya han sido explicados en las secciones previas. En este apartado vamos a tratar la configuración del directorio donde se almacenarán los logs y la gestión que debemos hacer de los mismos (rotado automático o no, backup, borrado manual…). 2.1. JBoss

165

Por defecto los logs se almacenan en $JBOSS_HOME/server/default/log. En el fichero $JBOSS_HOME/server/default/conf/log4j.xml definimos los appenders con la ubicación y la política de rotado. <appender name="FILE" class="org.jboss.logging.appender.DailyRollingFileAppender"> <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/> <param name="File" value="${jboss.server.log.dir}/server.log"/> <param name="Append" value="true"/>  <param name="DatePattern" value="'.'yyyy-MM-dd"/> En el ejemplo, se ha definido el fichero server.log que se ubicará en el directorio de jboss.server.log.dir (actualmente $JBOSS_HOME/server/default/log). El fichero rotará cada media noche ya que el DatePattern aplicado consiste en concatenar al fichero de log la fecha en formato yyyy-MM-dd. Ejemplo: El log server.log a partir de las 00:00h, si sucede un evento que deba escribir en el log disparará el rotado automático pasando a renombrarse el fichero server.log a server.log.2008-09-30 y se creará un nuevo fichero server.log. Los niveles de verbosidad y paquetes se configuran en las secciones siguientes: <category name="org.springframework"> <priority value="INFO"/> </category> <category name="ServiceErrorsLogger"> <priority value="ERROR" /> <appender-ref ref="ServiceErrors"/> </category> <category name="es.pode"> <priority value="INFO"/> <appender-ref ref="agrega"/> </category> <category name="es.agrega"> <priority value="INFO"/> <appender-ref ref="agrega"/> </category> En las categorías especificamos el paquete Java, la prioridad a mostrar (DEBUG, INFO, WARN, ERROR, FATAL) y podemos especificar uno o más appenders en los que se escribirán los logs de las clases pertenecientes al paquete. Todos los loggers heredan de la categoría raíz, definida de la siguiente manera: <root> <priority value="INFO"/> <appender-ref ref="CONSOLE"/> <appender-ref ref="FILE"/> </root>

166

Si queremos cambiar la prioridad de todas las clases por defecto a INFO, es importante introducir la línea “<priority value ="info" />” dentro de la sección root previa. Los valores almacenados en las categorías citadas anteriormente prevalecen sobrescribiendo los valores de la categoría root. 2.2. Apache Una vez confirmado que se encuentra presente el módulo en la configuración de Apache (httpd.conf) LoadModule log_config_module modules/mod_log_config.so, en cada fichero de configuración del virtual host especificamos tanto el formato de log a emplear como el fichero donde almacenarlo. LogFormat "%h %l %u %t \"%r\" %>s %b" extendedlog CustomLog logs/<sitio>_access.log extendedlog ErrorLog logs/<sitio>_error.log Con las líneas anteriores definimos el formato de log denominado “extendedlog” que estará formado por la cadena:

Opción Descripción %h Remote Host

%l Remote logname (from identd, if supplied). This will return a dash unless IdentityCheck is set On.

%u Remote user (from auth; may be bogus if return status (%s) is 401) %t Time the request was received (standard english format) %r First line of request

%>s Status. For requests that got internally redirected, this is the status of the *original* request --- %...>s for the last.

%b Size of response in bytes, excluding HTTP headers. In CLF format, i.e. a '-' rather than a 0 when no bytes are sent.

Un ejemplo de traza de log de acceso sería la siguiente: 172.22.52.81 - - [21/Oct/2008:10:48:37 +0200] "GET /visualizadorcontenidos/AcercaDeAgrega/AcercaDeAgrega.do HTTP/1.1" 200 13701 "redes.agrega.indra.es" "http://redes.agrega.indra.es/visualizadorcontenidos/Portada/Portada.do;jsessionid=F6C5CD845FC095CD37BA0096495AFA31" "Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3" 50542 Posteriormente definimos que el log <sitio>_access.log use el formato del extendedlog, por lo que en /var/log/httpd/ aparecerá un fichero llamado <sitio>_access.log. Las trazas de error de Apache al acceder al nodo se reflejarán en el fichero <sitio>_error.log. 2.2.1. Mod_jk En el fichero mod_jk.conf definimos el directorio, fichero, nivel y formato del log mediante las sentencias:

167

# Where to put jk logs JkLogFile "/var/log/httpd/mod_jk.log" # Set the jk log level [debug/error/info] JkLogLevel info # Select the log format JkLogStampFormat "[%a %b %d %H:%M:%S %Y]" De esta forma, en el directorio /var/log/httpd/mod_jk.log aparecerán las entradas en las que se define la fecha del acceso, el nodo al que se accede y el tiempo necesario para servir la petición (desde que se envía al JBoss hasta que se retorna a Apache). Un ejemplo de traza podría ser el siguiente: [Mon Oct 20 17:04:50 2008]contenidos contenidos.proyectoagrega.es 0.173134 2.3. MySQL Si en el fichero de configuración my.cnf se ha habilitado la opción “log-bin” (generalmente especificamos logbin=mysql-bin para que los ficheros de log se nombren con el valor especificado) se podrán auditar posteriormente los logs en /var/lib/mysql/. Por defecto, existirá un log de error asociado a la base de datos Agrega, y si se ha habilitado la opción de los logs binarios, existirán diversos ficheros /var/lib/mysql/mysql-bin.000XYZ. Para poder visualizar el contenido de los ficheros, es necesario hacer uso de la aplicación mysqlbinlog proporcionada junto a la BD. La sintaxis es: mysqlbinlog log_file Es conveniente tener en cuenta que si se habilita la opción de log-bin es necesario controlar el tamaño y número de ficheros de log generados por la aplicación, ya que contiene todas las sentencias SQL ejecutadas sobre la BD. 2.4. LDAP En el archivo slapd.conf se especifica el nivel de registro de los logs mediante el parámetro loglevel. Para especificar el fichero donde almacenar los logs es necesario saber que OpenLDAP por defecto envía su información de registro al demonio del sistema syslog (syslogd) bajo el canal LOCAL4. Para poder almacenar la información en un fichero que nosotros especifiquemos es necesario modificar el archivo /etc/syslog.conf, agregando una línea como la siguiente: local4.* /var/log/openldap De esta manera, conseguimos que los logs de OpenLDAP se almacenen en el fichero /var/log/openldap. El cambio en el fichero syslog.conf requiere reiniciar la máquina para que los cambios tengan efecto.

168


1 h


3. Backups En esta sección trataremos de identificar aquellos contenidos que es conveniente tener un backup. El manual pretende ser una guía resaltando las áreas a salvaguardar, no un procedimiento firme y único para la realización de los backup. En cada comunidad, existirá ya previamente un proceso de backup y deberá seguirse y respetarse, añadiendo ahora los nuevos ficheros, configuraciones, BD que soportan el portal Agrega. 3.1. Bases de datos Tanto en el caso de actualizaciones de Agrega que afecten a base de datos como cada cierto período de tiempo es conveniente realizar una backup de la base de datos. Los backups podrían ser deltas o completos. En función de la base de datos existirán unos u otros procedimientos aconsejados. En el caso de la instalación de Agrega sobre una base de datos MySQL, para realizar un backup completo de la BD (tanto tablas como datos) se aconseja el siguiente procedimiento: mysqldump --opt -c -e -Q –h $HOST --hex-blob -u usuario -ppassword $DBNAME > $BACKUP_DIR/$DATABASE-dump-$FECHA.sql Si únicamente deseamos las sentencias insert (los datos pero no la estructura de las tablas) podemos ejecutar el siguiente comando: mysqldump -u $USUARIO -p -h $HOST --insert-ignore -c --no-create-db --no-create-info --skip-add-locks --extended-insert=false --hex-blob -B $DATABASE > $BACKUP_DIR/$DATABASE-dump-$FECHA.sql En el caso del backup completo, para restaurar un backup habría que borrar la base de datos, crearla y posteriormente importar el dump:

1. Nos conectamos con el usuario administrador de la base de datos y ejecutamos: drop $DATABASE; create $DATABASE;

2. Desde la shell del SO, ejecutamos: mysql –h $HOST -u $USUARIO -p < $BACKUP_DIR/$DATABASE-dump-$FECHA.sql

169

3.2. OpenLDAP En el caso de haber instalado OpenLDAP, existen varias alternativas para hacer el backup del contenido del mismo. Para asegurar la consistencia del ldif generado, es necesario parar el servicio de LDAP previamente. Si se está empleando bdb, el comando sería:

/usr/sbin/slapcat -v -l $BACKUP_DIR/ldap.ldif Si se esta usando lbdm:

/usr/sbin/ldbmcat -n /var/lib/ldap/id2entry.gdbm > BACKUP$DIR/ldap.ldif

Para hacer una restauración completa a partir del ldif generado los pasos serían los siguientes:

1. Paramos el demonio slapd (/etc/init.d/ldap stop). 2. Borramos todos los datos del ldap (/var/lib/ldap). 3. Cargamos los datos del ldif mediante el comando: slapadd –v –c –l

backup.ldif 4. Regeneramos los índices con slapindex 5. Reiniciamos el demonio del ldap (/etc/init.d/ldap start).

3.3. Módulos WAR La mayor parte de las actualizaciones de Agrega llevarán asociadas la modificación de uno o más módulos WAR de la plataforma. Por ello, se recomienda hacer un backup del directorio $JBOSS_HOME/server/default/deploy/agrega. Es conveniente destacar que los módulos WAR ya se encuentran en formato ZIP, por lo que intentar aplicar cualquier algoritmo de compresión apenas reducirá el espacio. Si bien, para agrupar todos los módulos en un mismo fichero se puede emplear el TAR de Linux. A modo de ejemplo: tar cvfp $BACKUP_DIR/backup.tar $JBOSS_HOME/server/default/deploy/agrega/*.war 3.4. Índices Un componente fundamental de la plataforma son los índices. Las políticas de backup sugeridas son:

• Es altamente recomendable hacer un backup de los índices todos los días, a una hora en la que no existan operaciones pendientes en disco tales como carga de ODEs, generación de informes, etc.

• Cada vez que se haga una parada y arranque de la aplicación para efectuar alguna migración o actualización, es obligatorio salvaguardar la información de los índices una vez que el servidor de aplicaciones se encuentra parado.

El comando empleado para realizar el backup de los índices podría ser: tar cvfp $BACKUP_DIR/indices.tar $JBOSS_HOME/indices/*

170

3.5. Informes El directorio $JBOSS_HOME/informes es susceptible de ser salvaguardado. En algunas ocasiones, las actualizaciones de Agrega conllevarán la modificación de algunas plantillas que se emplean en la elaboración de los informes y cuya ubicación es $JBOSS_HOME/informes/plantillasInformes. 3.6. Ficheros de configuración del portal Debido a que los ficheros de configuración del portal contienen información tal como la dirección IP del servidor de LDAP, la IP del servidor de base de datos, periodicidad de la generación de informes, etc., no sólo en cada actualización de Agrega se modificarán los ficheros de configuración del portal, sino también en cada modificación que la comunidad realice sobre los elementos de la infraestructura. Por todo ello, es conveniente hacer backups antes de realizar cualquier modificación en los ficheros del portal. El comando a emplear podría ser el siguiente: tar czvfp $BACKUP_DIR/conf.tar.gz $JBOSS_HOME/server/default/conf 3.7. Estáticos En los procesos de actualización de la plataforma se actualizarán los ficheros estáticos (CSS, JS, JPG…) siendo necesario la realización de un backup previo a la actualización. El directorio a salvaguardar será aquel especificado en el alias del virtual host de Apache. Asumiendo que es /opt/static el backup se podría realizar mediante el comando: tar czvfp $BACKUP_DIR/estaticos.tar.gz /opt/static 3.8. Programación de backups en CRON Una vez completados los “scripts” de backups, editamos el fichero crontab para añadir nuestras tareas. Ejecutamos el comando crontab –e # Ejecuta un script que realiza un backup de la base de datos el primer día de cada mes a las 22:00 0 22 1 * * /home/backup/script_bd.sh # Más ejemplos 0 2 * * 1-6 sh /raid/Backups_Data/pruebas/MyBackup.sh Diario 0 2 * * 0 sh /raid/Backups_Data/pruebas/MyBackup.sh Semanal 0 2 1 * * sh /raid/Backups_Data/pruebas/MyBackup.sh Mensual El momento de ejecución se especifica de acuerdo con la siguiente tabla: Minutos: (0-59) Horas: (0-23) Días: (1-31) Mes: (1-12) Día de la semana: (0-6), siendo 1=Lunes, 2=Martes,... 6=sábado y 0=Domingo Para especificar todos los valores posibles de una variable se utiliza un asterisco (*).

171


1 h


4. Modificaciones frente a cambios frecuentes El objetivo de la sección es conocer exactamente los ficheros a cambiar considerando las modificaciones más frecuentes que suelen darse en los entornos de producción. A modo de ejemplo las modificaciones más comunes son: cambio de IP de la base de datos, cambio de los datos de acceso al LDAP, cambio de usuario o contraseña de conexión a la base de datos… 4.1. Modificación de la base de datos del portal Agrega A continuación veremos las moficaciones más comunes. 4.1.1. Modificación de la dirección IP Aunque normalmente la dirección especificada de la BD suele ser un alias, en caso de haberse especificado manualmente implicaría cambiar el fichero donde se definen los datasources: $JBOSS_HOME/server/default/deploy/<nodo>-ds.xml 4.1.2. Modificación de usuario/contraseña Por cada datasource definido en el fichero $JBOSS_HOME/server/default/deploy/<nodo>-ds.xml deberá ser revisada la configuración de acceso. 4.2. Modificación de la base de datos En caso de modificarse alguno de los parámetros de acceso a la base de datos que contiene la ayuda MediaWiki, será necesario revisar el fichero LocalSettings.php y modificar los parámetros que correspondan: $wgDBserver = "localhost"; $wgDBname = "db"; $wgDBuser = "user"; $wgDBpassword = "pass"; 4.3. Cambio de datos de conexión al LDAP Los datos de la conexión a LDAP se especifican en dos ficheros de configuración:

• $JBOSS_HOME/server/default/conf/authbackend.properties • $JBOSS_HOME/server/default/conf/springldap.xml

172

4.4. Cambio de IP del JBoss En el caso de cambiar la IP del servidor JBoss, si siempre se ha hecho referencia al alias definido en el /etc/hosts no será necesario realizar ninguna modificación (salvo la actualización en el hosts). En caso contrario, será necesario revisar el fichero: /etc/httpd/conf/workers.properties 4.5. Cambio de IP de Apache En caso de haber cambiado la IP del servidor web Apache, será necesario tenerlo en cuenta en el fichero /etc/hosts del servidor JBoss.


1 h


5. Tareas planificadas La plataforma dispone de un planificador de tareas basado en Quartz. El planificador permite programar tareas de mantenimiento de la plataforma y del repositorio:

• Carga de ODEs: Permite cargar al repositorio nuevos objetos educativos. • Reindexado: Borra los índices del nodo para rehacerlos. • Eliminar ODEs: Lanza un borrado de objetos del repositorio. • Generación de informes: Genera de forma programada un informe del tipo

especificado. El uso de Quartz permite una gestión eficiente de tareas planificadas que incluye la ejecución diferida de tareas (periódicas o no) y recuperación de tareas en caso de caída del servidor. Para ello, Quartz usa un modelo en base de datos propio que se carga con el resto de esquemas de datos de la plataforma. 5.1. Parámetros de configuración del planificador Las tareas de informes del planificador usan una serie de parámetros de configuración contenidos en el fichero $JBOSS_HOME/server/default/conf/agrega.properties. Estas propiedades permiten definir los directorios donde se almacenan los informes y los nombres de los ficheros asociados a cada tipo de informe. 5.2. Tareas A continuación se describen los tipos de tareas disponibles en la versión 1.0.3 de Agrega y lo recursos utilizados por dichas tareas en el servidor.

173

5.2.1. Carga de ODEs La carga de ODEs permite a un usuario administrador de la plataforma cargar contenidos al repositorio del nodo. Para poder realizar una carga de ODEs el usuario administrador necesita tener disponibles tres carpetas en el servidor. Estas carpetas deben tener permisos de lectura y escritura para el usuario de JBossAS y deben estar creadas en el momento de configurar la tarea. Dichas carpetas son:

• Carpeta de ODEs: En esta carpeta se almacenan los objetos en formato comprimido que el usuario administrador desea cargar al repositorio. En la versión actual (en el momento de escribir este manual) sólo se cargan los ODEs que estén a primer nivel, no se exploran las subcarpetas.

• Carpeta de ODEs correctos: Esta carpeta contiene los ODEs que la plataforma ha cargado correctamente al repositorio tras la ejecución de la tarea.

• Carpeta de ODEs erróneos: Esta carpeta contiene los ODEs que la plataforma no ha podido cargar debido a errores de validación de los objetos o a problemas en la aplicación.

5.2.2. Reindexado El usuario administrador de la plataforma puede programar un reindexado sobre uno de los índices de la plataforma. El reindexado supone borrar el índice actual y rehacerlo desde cero, por lo que es vital mantener backups de los índices para poder restaurarlos en caso de problemas. 5.2.3. Eliminación de ODEs La tarea de eliminación de ODEs elimina físicamente del servidor aquellos ODEs que previamente han sido despublicados por un usuario administrador. 5.2.4. Informes Las tareas restantes disponibles en el planificador corresponden a la generación de algún tipo de informe (Estado de los contenidos digitales educativos, Operaciones realizadas, Nivel de agregación, Cobertura curricular, etc). La plataforma gestiona de forma automática la generación de los informes y permite su consulta desde el portal de administración. Los ficheros físicos creados en el servidor están definidos en la configuración (fichero $JBOSS_HOME/server/default/conf/agrega.properties).


174

1 h


6. Generación automática de ficheros Dentro de la plataforma Agrega se encuentran configuradas por defecto unas tareas planificadas que permiten la generación periódica de algunos ficheros del portal, entre ellos se encuentran los informes de la portada, los ficheros de sitemaps, el contenido dinámico de la plataforma, los ficheros rss y el catálogo de contenidos de Agrega. A continuación se detallan cada una de las tareas. 6.1. Generación de los informes de portada Tarea automática de generación de los informes de la portada pública de Agrega. Los informes generados recogen información de los contenidos digitales educativos que más veces se ha mostrado su ficha de búsqueda, los que más veces han sido previsualizados, descargados, los ODEs más valorados o los términos más buscados. Este proceso es lanzado por la plataforma todos los días a las cuatro de la mañana y por defecto genera unos ficheros con la información del día anterior y otros con la información de los siete días anteriores. Este último parámetro al igual que el nombre de los ficheros y el número de contenidos digitales que como máximo saldrán en cada uno de los informes se pueden modificar dentro del fichero agrega.properties. 6.2. Generación de ficheros sitemap Tarea de generación de los ficheros de sitemaps que serán utilizados por Google para indexar los contenidos de la plataforma Agrega. Por defecto se lanza todos los días a la una de la mañana. Estos dos valores junto con el número de entradas que tendrá cada fichero sitemap y el nombre de los ficheros se pueden modificar en el fichero generacionContenidos.properties. 6.3. Generación del contenido dinámico de la plataforma Esta tarea programada genera el contenido dinámico de la plataforma, es decir, realiza la selección de una captura de un ODE aleatoriamente. Por defecto se lanza todos los días cada hora. Tanto la periodicidad como la hora en la que se lanza son valores configurables dentro del fichero generacionContenidos.properties. 6.4. Generación del catálogo Tarea de generación automática del catálogo de contenidos de Agrega con todos los contenidos digitales educativos con nivel de agregación mayor o igual que tres. Por defecto esta tarea se lanza una vez al mes a las cinco de la mañana. El fichero

175

resultante con el catálogo se almacena en el directorio referenciado por el atributo destinoInformesDir del fichero agrega.properties. 6.5. Generación de rss Esta tarea genera los ficheros rss con las últimas diez noticias, los últimos diez ODEs publicados y los contenidos digitales educativos más descargados, más previsualizados y más mostrados en la última semana, en el último mes y el último año. Por defecto se lanza todos los días a las dos de la mañana. Los ficheros generados se almacenan en el directorio referenciado por el atributo rss.path del fichero agrega.properties.


45 min


7. Seguridad En la presente sección trataremos de citar las mínimas recomendaciones de seguridad tanto para JBoss como para Apache. A nivel de base de datos bastaría con filtrar el acceso de los usuarios por IPs a la misma. 7.1. Seguridad en JBoss A continuación se describen los pasos a seguir para asegurar la Consola JMX y la Consola Web del JBoss. 7.1.1. Asegurar la Consola JMX Restringimos el acceso a la consola JMX con un usuario y contraseña, para ello seguimos los siguientes pasos:

1. Localizar el directorio jmx-console.war, por defecto está en: $JBOSS_HOME/server/default/deploy

2. Editar el archivo web.xml que está bajo el directorio jmx-

console.war/WEB-INF y descomentar los bloques de seguridad quedando así:

 <security-constraint> <web-resource-collection> <web-resource-name>HtmlAdaptor</web-resource-name> <description>An example security config that only allows users with the role JBossAdmin to access the HTML JMX console web application </description> <url-pattern>/*</url-pattern> <http-method>GET</http-method>

176

<http-method>POST</http-method> </web-resource-collection> <auth-constraint> <role-name>JBossAdmin</role-name> </auth-constraint> </security-constraint>

3. Editar el fichero jboss-web.xml y descomentar también el elemento security-domain como sigue:

<jboss-web>  <security-domain>java:/jaas/jmx-console</security-domain> </jboss-web>

4. Localizar los dos ficheros de propiedades llamados como jmx-console-users.properties y jmx-console-roles.properties que estarán en el directorio conf de la configuración del servidor, bajo el subdirectorio props. Un ejemplo de está localización sería: /server/default/conf/props.

5. En jmx-console-users.properties, añadir/cambiar la combinación

usuario/contraseña.

6. En jmx-console-roles.properties, añadir los roles asignados a los usuarios que se han añadido o cambiado en el paso anterior. Recordar añadir el role JBossAdmin a los usuarios los cuales estén usando la jmx-console.

7. Por último, cuando se arranque ahora el servidor de aplicaciones JBoss y se

trate de acceder a la jmx-console se debe obtener un pop up solicitando el usuario y contraseña.

7.1.2. Asegurar la Consola Web Restringimos el acceso a la Consola Web con usuario y contraseña: el proceso es similar al anterior. En el directorio /deploy localizamos management/web-console.war y realizamos los mismos cambios en WEB-INF/web.xml, WEB-INF/jboss-web.xml y en los ficheros de propiedades de usuarios y grupos. 7.2. Seguridad en Apache Las recomendaciones generales en cuanto a la seguridad de Apache son las siguientes:

• Se recomienda estar al día en los últimos parches de seguridad para continuar con la optimización de seguridad.

• Apache debe funcionar bajo su propia cuenta y grupo de usuario. Algunas

versiones de Apache corren bajo el usuario nobody, esto compromete mucho su seguridad.

• Es necesario instalar PHP como un módulo de Apache, en lugar de CGI, para

177

dotar al sistema de una mayor seguridad, y también más potencia.

• Asegurar que los archivos a los que se accede son los deseados. No deseamos que se pueda acceder a los directorios que no tengan permisos para ello.

• En la configuración de los virtual hosts, se definen las restricciones

anteriores, por ejemplo: # security # forbid default access to filesystem locations <Directory /> Order Deny,Allow Deny from all AllowOverride None php_flag engine off </Directory> <Directory "/export/ccaa/<sitio>/uploads"> Order Deny,Allow Allow from all AllowOverride None php_flag engine off </Directory> <Directory "/export/wiki/wiki/"> Options None AllowOverride None Order Deny,Allow Allow from all php_flag engine on </Directory>

1. En el primer tag <Directory /> con la sentencia Deny from all se prohíbe por defecto el acceso a los directorios. Posteriormente se especifican dos bloques <Directory> permitiendo el acceso a las áreas que definimos.

2. La directiva php_flag engine on/off se utiliza para sitios que quieran

activar o desactivar el intérprete de PHP en función del directorio o del virtual host. En nuestro caso debemos evitar ejecutar contenido PHP a excepción de la ayuda MediaWiki.

3. La directiva Options None desactiva todas las opciones: no permitiendo la

ejecución de CGI, ni explorar directorios, ni seguir enlaces simbólicos y desactiva los includes.

4. Por último, la directiva AllowOverride None desactiva el acceso a los

archivos .htaccess.

178

15 min


8. Actualización MediaWiki Puesto que MediaWiki es un software wiki libre escrito originalmente para Wikipedia, se encuentra en continua evolución y corrección de incidencias de seguridad. Se aconseja visitar habitualmente la web oficial, siguiendo las recomendaciones de seguridad que allí se establezcan. Es importante destacar que al no haberse realizado ninguna modificación en el código de la MediaWiki, todos los procesos de actualización que se faciliten desde la web oficial deberían poder ser ejecutados sin afectar al comportamiento de la ayuda del portal Agrega.

Comprueba que JBoss está arrancado. Comprueba también la existencia de script de parada y arranque de JBoss.

Comprueba que Apache está arrancado. Comprueba también la existencia de script de parada y arranque de Apache.

Si la base de datos instalada es MySQL, comprueba que MySQL está arrancado. Comprueba también la existencia de script de parada y arranque de MySQL.

¿Dónde se define la ubicación del fichero de log del servidor JBoss?

¿Dónde se encuentran los parámetros de configuración de Agrega? (Por ejemplo, para la ejecución de tareas planificadas, creación de informes, generación de ficheros RSS, etc.)

¿Dónde se almacenan los ficheros de sitemap de Agrega?

179


Manual módulo 6 Integración

180

Índice Contenido del módulo 6 Integración 1. Introducción

2. WebServices publicados 2.1. Buscar 2.2. Entregar 3. OAI-PMH 3.1. Identify 3.2. ListMetadataFormats 3.3. Listsets 3.4. Listldentifiers 3.5. GetRecord 3.6. ListRecords 3.7. Errores 4. Gestor de sesiones

4.1. Alcance 4.2. Integración a través de WebServices

5. SQI


6. DRI


181

Módulo 6. Integración


• Objetivos

- Identificar los WebServices publicados por la plataforma Agrega.

- Manejar los ficheros WSDL que pueden ser accedidos para cada funcionalidad.

- Utilizar el protocolo OAI-PMH así como su funcionalidad. - Comprobar el funcionamiento de los métodos del protocolo

OAI-PMH. - Implementar la especificación SQI. - Implementar la especificación DRI.

• Contenidos

- Introducción - WebServices publicados - OAI-PMH - Gestor de sesiones - SQI - DRI


182

5 min


1. Introducción La plataforma de Agrega se concibe como un repositorio de almacenamiento de Objetos Digitales Educativos en la que se pone a disposición de los usuarios capacidades de creación, visualización, catalogación y compartición de sus contenidos. Para añadir valor a los objetos almacenados, potenciar su distribución y facilitar su acceso, se definen dentro de la comunidad educativa una serie de estándares, normas y protocolos que se orientan a la facilitación de los contenidos. Los repositorios, además de concebirse como almacenes de recursos digitales, contemplan un almacenamiento de metadatos para aportar información sobre los componentes y facilitar su compartición hacia el exterior sin necesidad de conocimiento previo de la organización o la estructura del almacén. Con estos fines, Agrega ofrece los interfaces de OAIPMH y DRI. No obstante, al tratarse de una arquitectura SOA, la mayor parte de los módulos expone una interfaz web vía WebServices que permitiría la integración de otros desarrollos con la plataforma. Los WebServices de los ejemplos podrán ser invocados mediante la herramienta gratuita SoapUI.

55 min


2. WebServices publicados Algunos módulos desplegados en el servidor de aplicaciones resultan de especial interés de cara a posibles integraciones desde otras plataformas. Cada módulo expone las operaciones y los WSDL que las describen siendo accesibles directamente desde cualquier navegador. 2.1. Buscar Buscar es el módulo de Agrega que ejecuta las búsquedas en el repositorio y se encarga de aunar y cachear los resultados en el caso de realizar búsquedas federadas. Depende del buscador, que es el módulo que trabaja con el índice. Desde esta funcionalidad se permite buscar conociendo el identificador del ODE y el idioma en el que esta catalogado:

• solicitarMetadato: busca en el repositorio por el idioma de catalogación la ficha del ODE.

• buscarAvanzado: permite la realización de búsquedas.

183

2.1.1. WSDL En la URL http://redes.agrega.indra.es/buscar-1/services se listan todos los servicios publicados, resultando de interés para realizar las búsquedas el siguiente servicio: http://redes.agrega.indra.es/buscar-1/services/SrvBuscarService?wsdl 2.1.2. Ejemplo Llamada: <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ser="http://servicios.buscar.negocio.buscar.pode.es"> <soapenv:Header/> <soapenv:Body> <ser:solicitarMetadato> <ser:parametros> <ser:identificadorODE>es_20070901_3_0260900</ser:identificadorODE> <ser:idioma>es</ser:idioma> <ser:busquedaSimpleAvanzada>POSICIONADO_DETALLE</ser:busquedaSimpleAvanzada> </ser:parametros> </ser:solicitarMetadato> </soapenv:Body> </soapenv:Envelope> Respuesta: se obtiene como respuesta los metadatos del ODE. <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <solicitarMetadatoResponse xmlns="http://servicios.buscar.negocio.buscar.pode.es"> <solicitarMetadatoReturn> <ambito> <ambito>universal</ambito> </ambito> <descripcion>Secuencia didáctica para el reconocimiento de situaciones de discriminación. Los cinco objetos que la componen simulan casos en los que se fomenta que el alumnado participa en proyectos de integración</descripcion> <destinatarios> <destinatarios>learner</destinatarios> <destinatarios>teacher</destinatarios> <destinatarios>family</destinatarios> <destinatarios>individual</destinatarios> </destinatarios> <formato> <formato>text/html</formato> <formato>audio/mpeg</formato> <formato>application/x-shockwave-flash</formato> <formato>text/xml</formato> <formato>application/pdf</formato> <formato>image/jpg</formato> <formato>image/gif</formato> </formato>

http://redes.agrega.indra.es/buscar-1/services

http://redes.agrega.indra.es/buscar-1/services/SrvBuscarService?wsdl

184

<identificadorODE>es_20070901_3_0260900</identificadorODE> <idioma>es</idioma> <imagen>/galeriaimg/es_20070901_3_0260900/es_20070901_3_0260900.png</imagen> <licencias> <licencias>creative commons: attribution - non commercial - share alike</licencias> </licencias> <localizadorODE>uploads/repositorio/23062008/es_20070901_3_0260900</localizadorODE> <nivelAgregacion>3</nivelAgregacion> <tamanio>13074256</tamanio> <titulo>Yo soy el otro</titulo> <valoracion>4.0</valoracion> </solicitarMetadatoReturn> </solicitarMetadatoResponse> </soapenv:Body> </soapenv:Envelope> 2.2. Entregar La plataforma AGREGA contiene un repositorio de Objetos Digitales Educativos, cumpliendo con la especificación SCORM 2004. Con SCORM se hace posible la creación de contenidos que puedan importarse dentro de sistemas de gestión de aprendizaje diferentes, siempre que estos soporten la norma SCORM. Los principales requerimientos que el modelo SCORM trata de satisfacer son:

• Accesibilidad: capacidad de acceder a los componentes de enseñanza desde un sitio distante a través de las tecnologías web, así como distribuirlos a otros sitios.

• Adaptabilidad: capacidad de personalizar la formación en función de las necesidades de las personas y organizaciones.

• Durabilidad: capacidad de resistir a la evolución de la tecnología sin necesitar una reconcepción, una reconfiguración o una reescritura del código.

• Interoperabilidad: capacidad de utilizarse en otro emplazamiento y con otro conjunto de herramientas o sobre otra plataforma de componentes de enseñanza desarrolladas dentro de un sitio, con un cierto conjunto de herramientas o sobre una cierta plataforma. Existen numerosos niveles de interoperabilidad.

• Reusabilidad: flexibilidad que permite integrar componentes de enseñanza dentro de múltiples contextos y aplicaciones.

De acuerdo con estos requerimientos, el módulo Entregar permite el intercambio de ODEs del repositorio de la plataforma, reutilización por plataformas que soportan modelos anteriores, como SCORM 1.2 o IMS-CP, y además se permite reutilizar los recursos de los ODEs, de manera que el educador o el alumno pueda utilizar o visualizar los recursos sin necesidad de una herramienta de gestión del aprendizaje. 2.2.1. WSDL El WSDL puede ser accedido desde la URL: http://redes.agrega.indra.es/entregar-

http://redes.agrega.indra.es/entregar-1/services/SrvEntregarService?wsdl

185

1/services/SrvEntregarService?wsdl Veamos los métodos publicados más interesantes:

• generarPaquetePIF: este método necesita como parámetro una cadena de caracteres conteniendo el identificador del Objeto Digital Educativo que se solicita. Como salida obtiene un objeto del tipo PaquetePifVO, conteniendo el ODE empaquetado con formato SCORM2004 y mensajes de error, en caso de producirse.

• obtenerTiposPIF: devuelve un array de Strings con los tipos soportados por la plataforma. Actualmente son: - SCORM_2004 - SCORM_2004_SIN_SUBMANIFIESTO - SCORM_12 - IMS_CP - HTML - CONTENIDOS

• generarPaquetePIFTipoPIF: este método necesita como parámetro un objeto del tipo TipoPifVO que empaqueta el identificador del ODE solicitado, el formato de exportación elegido y el idioma de exportación. Se obtiene como salida un objeto del tipo PaquetePifVO, descrito anteriormente.

2.2.2. Ejemplos Ejemplo 01: llamada al método generarPaquetePif solicitando un ODE que es válido. Llamada: <?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <generarPaquetePIF xmlns="http://servicios.negocio.entregar.pode.es"> <identificador>ODE-fd61edbc-ee56-38d4-9352-41bab971b013</identificador> </generarPaquetePIF> </soapenv:Body> </soapenv:Envelope> Respuesta: se obtiene como respuesta un mensaje SOAP conteniendo la información devuelta por el método y un attach conteniendo el ODE serializado. ------=_Part_1_31262813.1214307945828 Content-Type: text/xml; charset=UTF-8 Content-Transfer-Encoding: binary Content-Id: <08C458B838D1365A5864E6985429AF52> <?xml version="1.0" encoding="utf-8"?> <soapenv:Envelope

http://redes.agrega.indra.es/entregar-1/services/SrvEntregarService?wsdl

186

xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <generarPaquetePIFResponse xmlns="http://servicios.negocio.entregar.pode.es"> <generarPaquetePIFReturn> <paquetePIF href="cid:74D53F983C9A2A6730C4D468C80BF990"/> <resultadoValidacion> <esValidoManifest>true</esValidoManifest> <resultadoValidacion></resultadoValidacion> <rutaManifest xsi:nil="true"/> </resultadoValidacion> </generarPaquetePIFReturn> </generarPaquetePIFResponse> </soapenv:Body> </soapenv:Envelope> ------=_Part_1_31262813.1214307945828 Content-Type: application/octet-stream Content-Transfer-Encoding: binary Content-Id: <74D53F983C9A2A6730C4D468C80BF990> {…. contenido binario del DataHandler…} Ejemplo 02: llamada al método generarPaquetePif solicitando un ODE que no es válido. Llamada: <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:enc="http://schemas.xmlsoap.org/soap/encoding" > <soap:Body> <impl:generarPaquetePIF xmlns:impl="http://servicios.negocio.entregar.pode.es"> <impl:identificador>ODE-387f38a4-0f82-3492-b9b5-a28eb3f0bbcd</impl:identificador> </impl:generarPaquetePIF> </soap:Body> </soap:Envelope> Respuesta: se obtiene como respuesta solo el mensaje SOAP con la información necesaria para saber porque el ODE no fue entregado. <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <generarPaquetePIFResponse xmlns="http://servicios.negocio.entregar.pode.es"> <generarPaquetePIFReturn> <paquetePIF xsi:nil="true"/> <resultadoValidacion><esValidoManifest>false</esValidoManifest> <resultadoValidacion>Al menos un elemento (item) es obligatorio dentro de una organización ;Error LOM-ES, Metadatos incorrectos;</resultadoValidacion> <rutaManifest xsi:nil="true"/> </resultadoValidacion> </generarPaquetePIFReturn>

187

</generarPaquetePIFResponse> </soapenv:Body> </soapenv:Envelope> Ejemplo 03: llamada al método generarPaquetePifTipoPif solicitando un ODE que es válido. Llamada: <?xml version="1.0" encoding="utf-8"?> <soap:Envelope

xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:enc="http://schemas.xmlsoap.org/soap/encoding">

<soap:Body> <impl:generarPaquetePIFTipoPIF xmlns:impl="http://servicios.negocio.entregar.pode.es"> <impl:tipoPifVO> <impl:idODE>ODE-fd61edbc-ee56-38d4-9352-41bab971b013</impl:idODE> <impl:tipoPif>SCORM_2004</impl:tipoPif> <impl:idioma>es</impl:idioma> </impl:tipoPifVO> </impl:generarPaquetePIFTipoPIF> </soap:Body> </soap:Envelope> Respuesta: se obtiene como respuesta un mensaje SOAP conteniendo la información devuelta por el método y un attach conteniendo el ODE serializado. ------=_Part_8_24005374.1214321990043 Content-Type: text/xml; charset=UTF-8 Content-Transfer-Encoding: binary Content-Id: <AD48DDF0E86D4BD7DC1D8883665A86> <?xml version="1.0" encoding="utf-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <generarPaquetePIFTipoPIFResponse xmlns="http://servicios.negocio.entregar.pode.es">

<generarPaquetePIFTipoPIFReturn> <paquetePIF href="cid:86JD2583DDE885DE5E5GF56H7HH331"/> <resultadoValidacion>

<esValidoManifest>true</esValidoManifest> <resultadoValidacion></resultadoValidacion>

<rutaManifest xsi:nil="true"/> </resultadoValidacion>

188

</generarPaquetePIFTipoPIFReturn> </generarPaquetePIFTipoPIFResponse> </soapenv:Body> </soapenv:Envelope> ------=_Part_8_24005374.1214321990043 Content-Type: application/octet-stream Content-Transfer-Encoding: binary Content-Id: <86JD2583DDE885DE5E5GF56H7HH331> {…. contenido binario del DataHandler…}

Proyecta las diapositivas 138 y 139.

1 h 30 min


3. OAI-PMH OAI-PMH (Open Archives Initiative Protocol for Metadata Harvesting) se define como un protocolo para la transmisión de metadatos a través de Internet. En este protocolo participan dos tipos de agentes:

• Proveedores de datos: exponen públicamente sus metadatos codificados en Dublín Core en un fichero xml.

• Proveedores de servicios: realizan servicios de búsqueda para recopilar

(harvesting) los metadatos de un proveedor. La comunicación con el proveedor de datos se realiza mediante llamadas HTTP.

Desde la plataforma Agrega se ofrece la posibilidad de integración con su repositorio a través del protocolo OAI-PMH actuando como proveedora de datos. Un cliente que quiera obtener información del repositorio de Agrega deberá establecer una comunicación con la plataforma mediante una llamada HTTP a una dirección pública de Internet que se facilitará en la plataforma. En dicha comunicación se deberán parametrizar los términos en los que se realiza la petición (de la manera que veremos más adelante), a lo que la plataforma Agrega contestará en el contexto de la misma petición (de forma síncrona) con el resultado de la operación, indicando el éxito de la misma o la causa de su fracaso. A continuación, se detallan todos los métodos del protocolo OAI-PMH implementados en Agrega. 3.1. Identify Este método devuelve la información sobre el servidor de OAI-PMH, tales como el

189

nombre, la versión del protocolo, el correo del administrador de la plataforma, etc. 3.1.1. Argumentos verb: Obligatorio. Se pasará la operación que se quiere realizar en este caso Identify. 3.1.2. Formato de la llamada La manera de obtener información sobre el repositorio es mediante una llamada HTTP al método Identify del repositorio: http://urlRepositorioAgrega?verb=Identify 3.1.3. Formato de salida Como respuesta el Agrega devolverá un XML codificado en UTF-8 con toda la información del repositorio. 3.1.4. Ejemplo A continuación se describe un ejemplo de llamada al método Identify y la correspondiente respuesta obtenida: http://redes.agrega.indra.es/oaipmh/OaiPmhRequest/OaiPmhRequest.do?verb=Identify <?xml version="1.0" encoding="UTF-8"?> <OAI-PMH xmlns:oai_id="http://www.openarchives.org/OAI/2.0/oai-identifier" xmlns="http://www.openarchives.org/OAI/2.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd http://www.openarchives.org/OAI/2.0/oai-identifier http://www.openarchives.org/OAI/2.0/oai-identifier.xsd"> <responseDate>2008-06-19T17:18:54.653+02:00</responseDate> <request verb="Identify"> http://redes.agrega.indra.es/oaipmh/OaiPmhRequest/OaiPmhRequest.do </request> <Identify> <repositoryName>Agrega</repositoryName> <baseURL>http://redes.agrega.indra.es/oaipmh/OaiPmhRequest/OaiPmhRequest.do</baseURL> <protocolVersion>2.0</protocolVersion> <adminEmail>[email protected]</adminEmail> <earliestDatestamp>2008-03-14</earliestDatestamp> <deletedRecord>no</deletedRecord> <granularity>YYYY-MM-DD</granularity> <description> <oai_id:oai-identifier> <oai_id:scheme>oai</oai_id:scheme> <oai_id:repositoryIdentifier>agrega.es</oai_id:repositoryIdentifier> <oai_id:delimiter>:</oai_id:delimiter>

http://redes.agrega.indra.es/oaipmh/OaiPmhRequest/OaiPmhRequest.do?verb=Identify

http://redes.agrega.indra.es/oaipmh/OaiPmhRequest/OaiPmhRequest.do?verb=Identify

http://www.openarchives.org/OAI/2.0/oai-identifier

190

<oai_id:sampleIdentifier>oai:agrega.es:identificadorMec</oai_id:sampleIdentifier> </oai_id:oai-identifier> </description> </Identify> </ OAI-PMH>

3.2. ListMetadataFormats Devuelve el listado de los tipos de metadatos que soporta el proveedor. En el caso de la plataforma Agrega sólo se va a soportar el tipo de metadato Dublín Core. 3.2.1. Argumentos

• verb: Obligatorio. Operación que se quiere realizar en este caso ListMetadataFormats.

• Identifier: Optativo. En el caso de añadir este parámetro se devolverían únicamente los tipos de metadatos en los que esta disponible el objeto del repositorio cuyo identificador se pasa.

3.2.2. Formato de la llamada http://urlRepositorioAgrega?verb=ListMetadataFormats 3.2.3. Formato de salida Como resultado se obtendrá un xml con los tipos de metadatos. 3.2.4. Ejemplo http://redes.agrega.indra.es/oaipmh/OaiPmhRequest/OaiPmhRequest.do?verb=ListMetadataFormats <?xml version="1.0" encoding="UTF-8"?> <OAI-PMH xmlns="http://www.openarchives.org/OAI/2.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd"> <responseDate>2008-06-19T18:51:36.471+02:00</responseDate> <request verb="ListMetadataFormats">http://redes.agrega.indra.es/oaipmh/OaiPmhRequest/OaiPmhRequest.do</request> <ListMetadataFormats> <metadataFormat> <metadataPrefix>oai_dc</metadataPrefix> <schema>http://www.openarchives.org/OAI/2.0/oai_dc.xsd</schema> <metadataNamespace>http://www.openarchives.org/OAI/2.0/oai_dc/</metadataNamespace> </metadataFormat> </ListMetadataFormats> </ OAI-PMH>

http://redes.agrega.indra.es/oaipmh/OaiPmhRequest/OaiPmhRequest.do?verb=ListMetadataFormats

http://redes.agrega.indra.es/oaipmh/OaiPmhRequest/OaiPmhRequest.do?verb=ListMetadataFormats

191

3.3. Listsets Devuelve el listado de conjuntos soportados por el proveedor de contenidos. Estos conjuntos son creados opcionalmente por el servidor para facilitar una recuperación selectiva de los registros. Sería una clasificación de los contenidos según diferentes entradas, así un cliente podría pedir que se recuperasen solo los registros pertenecientes a una determinada clase. Los conjuntos pueden ser simples listas o estructuras jerárquicas. En el caso de la plataforma Agrega no se van a soportar los conjuntos. 3.3.1. Argumentos

• verb: Obligatorio. Operación que se quiere realizar en este caso ListSets. • resumptionToken: Optativo. Token necesario para el control de flujo. Este

atributo será utilizado por más métodos del protocolo para permitir el paginado de la respuesta.

3.3.2. Formato de llamada http://urlRepositorioAgrega?verb=ListSets 3.3.3. Formato de salida Como resultado se obtendrá un xml con los conjuntos. 3.3.4. Ejemplo http://redes.agrega.indra.es/oaipmh/OaiPmhRequest/OaiPmhRequest.do?verb=ListSets <?xml version="1.0" encoding="UTF-8"?> <OAI-PMH xmlns="http://www.openarchives.org/OAI/2.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd"> <responseDate>2008-06-19T18:59:35.763+02:00</responseDate> <request verb="ListSets">http://redes.agrega.indra.es/oaipmh/OaiPmhRequest/OaiPmhRequest.do</request> <error code="noSetHierarchy">La plataforma no soporta conjuntos</error> </OAI-PMH> 3.4. ListIdentifiers Recupera los identificadores de los registros de la plataforma, en lugar de los registros completos. Permite argumentos como el rango de fechas entre los que queremos recuperar los datos. 3.4.1. Argumentos

• verb: Obligatorio. Operación que se quiere realizar en este caso ListIdentifiers.

• from: Opcional. Fecha a partir de la cual se quiere obtener la lista

192

selectiva de identificadores. • until: Opcional. Fecha hasta la cual se quiere obtener la lista selectiva de

identificadores. • metadataPrefix: Obligatorio. Tipo de metadato que deben soportar los

identificadores. En el caso de la plataforma Agrega será oai_dc (Dublín Core) ya que es el único tipo de metadato soportado.

• Set: Opcional. Identificador del conjunto. • resumptionToken: Opcional. Token necesario para el control de flujo.

3.4.2. Formato de la llamada http://urlRepositorioAgrega?verb=ListIdentifiers&metadataPrefix=oai_d 3.4.3. Formato de salida Como resultado se obtendrá un xml con la lista de los identificadores. 3.4.4. Ejemplo http://redes.agrega.indra.es/oaipmh/OaiPmhRequest/OaiPmhRequest.do?verb=ListIdentifiers&metadataPrefix=oai_dc <?xml version="1.0" encoding="UTF-8"?> <OAI-PMH xmlns="http://www.openarchives.org/OAI/2.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd"> <responseDate>2008-06-19T19:24:45.759+02:00</responseDate> <request verb="ListIdentifiers" metadataPrefix="oai_dc">http://redes.agrega.indra.es/oaipmh/OaiPmhRequest/OaiPmhRequest.do </request> <ListIdentifiers> <header> <identifier>oai:agrega.es:es-ic_20080410_1_9075517</identifier> <datestamp>2008-04-10</datestamp> </header> <header> <identifier>oai:agrega.es:es-ic_20080430_1_9135930</identifier> <datestamp>2008-04-30</datestamp> </header> <header> <identifier>oai:agrega.es:es-ic_20080613_3_9140808</identifier> <datestamp>2008-06-13</datestamp> </header> <header> <identifier>oai:agrega.es:es-ic_20080613_2_9140827</identifier> <datestamp>2008-06-13</datestamp> </header> <header>

193

<identifier>oai:agrega.es:es-ic_20080613_2_9140821</identifier> <datestamp>2008-06-13</datestamp> </header> <header> <identifier>oai:agrega.es:es-ic_20080613_2_9140834</identifier> <datestamp>2008-06-13</datestamp> </header> <header> <identifier>oai:agrega.es:es_20071116_3_0182000</identifier> <datestamp>2008-06-13</datestamp> </header> <header> <identifier>oai:agrega.es:es_20071116_3_0162000</identifier> <datestamp>2008-06-13</datestamp> </header> <header> <identifier>oai:agrega.es:es_20071214_2_0102001</identifier> <datestamp>2008-06-13</datestamp> </header> <header> <identifier>oai:agrega.es:es_20071116_2_0162001</identifier> <datestamp>2008-06-13</datestamp> </header> <resumptionToken expirationDate="2008-06-19T19:24:45.796+02:00" completeListSize="255" cursor="0">1213896285756</resumptionToken> </ListIdentifiers> </OAI-PMH> 3.5. GetRecord Recupera la información de un registro concreto del repositorio. 3.5.1. Argumentos

• verb: Obligatorio. Se pasará la operación que se quiere realizar en este caso GetRecord.

• identifier: Obligatorio. Identificador del registro del que se quiere obtener la información.

• metadataPrefix: Obligatorio. Tipo de metadato. Como se ha comentado anteriormente la plataforma Agrega únicamente soporta oai_dc.

3.5.2. Formato de la llamada http://urlRepositorioAgrega?verb=GetRecord&metadataPrefix=oai_dc&identifier=identificadorRegistro 3.5.3. Formato de salida Como resultado se obtendrá un xml con la información del registro. 3.5.4. Ejemplo http://redes.agrega.indra.es/oaipmh/OaiPmhRequest/OaiPmhRequest.do?verb=GetRecord&metadataPrefix=oai_dc&identifier=oai:agrega.es:es-ic_20080410_1_9075517

http://redes.agrega.indra.es/oaipmh/OaiPmhRequest/OaiPmhRequest.do?verb=GetRecord&metadataPrefix=oai_dc&identifier=oai:agrega.es:es-ic_20080410_1_9075517



194

<?xml version="1.0" encoding="UTF-8"?> <OAI-PMH xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns="http://www.openarchives.org/OAI/2.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd http://www.openarchives.org/OAI/2.0/oai_dc/ http://www.openarchives.org/OAI/2.0/oai_dc.xsd"> <responseDate>2008-06-19T19:38:36.254+02:00</responseDate> <request verb="GetRecord" identifier="oai:agrega.es:es-ic_20080410_1_9075517" metadataPrefix="oai_dc">http://redes.agrega.indra.es/oaipmh/OaiPmhRequest/OaiPmhRequest.do</request> <GetRecord> <record> <header> <identifier>oai:agrega.es:es-ic_20080410_1_9075517</identifier> <datestamp>2008-04-10</datestamp> </header> <metadata> <oai_dc:dc> <dc:title>agrega : Dispositivo de anclaje en una herramienta eléctrica</dc:title> <dc:creator/> <dc:subject>útil</dc:subject> <dc:description>Fotografía detallada de una herramienta denominada espátula eléctrica en la que se aprecia su dispositivo de anclaje</dc:description> <dc:publisher>catalogado y financiado con fondos FEDER dentro del expediente 502/06-Lote1</dc:publisher> <dc:contributor/> <dc:date>2008-04-10</dc:date> <dc:type>photograph</dc:type> <dc:format>image/jpeg</dc:format> <dc:identifier>http://redes.agrega.indra.es/buscador/DetallarODECU/DetallarODECU.do?idioma=es&identificadorODE=es-ic_20080410_1_9075517</dc:identifier> <dc:source/> <dc:language>es</dc:language> <dc:relation/> <dc:coverage/> <dc:rights>creative commons: attribution - non commercial - share alike</dc:rights> </oai_dc:dc> </metadata> </record> </GetRecord> </OAI-PMH> 3.6. ListRecords Devuelve todos los registros del repositorio. Permite argumentos como el rango de fechas entre los que queremos recuperar los datos. 3.6.1. Argumentos

195

• verb: Obligatorio. Operación que se quiere realizar en este caso

ListRecords. • from: Opcional. Fecha a partir de la cual se quiere obtener la lista

selectiva de registros. • until: Opcional. Fecha hasta la cual se quiere obtener la lista selectiva de

registros. • metadataPrefix: Obligatorio. Tipo de metadato que deben soportar los

registros. En el caso de la plataforma agrega será oai_dc (Dublín Core). • Set: Opcional. Identificador del conjunto. • resumptionToken: Opcional. Token necesario para el control de flujo.

3.6.2. Formato de la llamada http://urlRepositorioAgrega?verb=ListRecords&metadataPrefix=oai_dc 3.6.3. Formato de salida Devuelve un xml con los registros del repositorio. 3.6.4. Ejemplo http://redes.agrega.indra.es/oaipmh/OaiPmhRequest/OaiPmhRequest.do?verb=ListRecords&metadataPrefix=oai_dc <?xml version="1.0" encoding="UTF-8"?> <OAI-PMH xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns="http://www.openarchives.org/OAI/2.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd http://www.openarchives.org/OAI/2.0/oai_dc/ http://www.openarchives.org/OAI/2.0/oai_dc.xsd"> <responseDate>2008-06-19T19:48:48.319+02:00</responseDate> <request verb="ListRecords" metadataPrefix="oai_dc">http://redes.agrega.indra.es/oaipmh/OaiPmhRequest/OaiPmhRequest.do</request> <ListRecords> <record> <header> <identifier>oai:agrega.es:es_20071116_2_0162001</identifier> <datestamp>2008-06-13</datestamp> </header> <metadata> <oai_dc:dc> <dc:title>agrega : Flexibilidad</dc:title> <dc:creator>Eptron Multimedia S.A.</dc:creator> <dc:subject>Flexibilidad</dc:subject> <dc:description>Definir de un modo comprensible para el alumnado la flexibilidad. Mostrar diferentes ejercicios para trabajar la flexibilidad.</dc:description> <dc:publisher>catalogado y financiado con fondos FEDER dentro del expediente 502/06-Lote1</dc:publisher> <dc:contributor/>

http://redes.agrega.indra.es/oaipmh/OaiPmhRequest/OaiPmhRequest.do?verb=ListRecords&metadataPrefix=oai_dc

http://redes.agrega.indra.es/oaipmh/OaiPmhRequest/OaiPmhRequest.do?verb=ListRecords&metadataPrefix=oai_dc

196

<dc:date>2008-06-13</dc:date> <dc:type>self assessment</dc:type> <dc:format>text/html</dc:format> <dc:identifier>http://redes.agrega.indra.es/buscador/DetallarODECU/DetallarODECU.do?idioma=es&identificadorODE=es_20071116_2_0162001</dc:identifier> <dc:source>es_20071116_3_0162000</dc:source> <dc:language>es</dc:language> <dc:relation>ispartof</dc:relation> <dc:coverage>Universal</dc:coverage> <dc:rights>creative commons: attribution - non commercial - share alike</dc:rights> </oai_dc:dc> </metadata> </record> <record> <header> <identifier>oai:agrega.es:es_20071116_2_0162001</identifier> <datestamp>2008-06-13</datestamp> </header> <metadata> <oai_dc:dc> <dc:title>agrega : Flexibilidad</dc:title> <dc:creator>Eptron Multimedia S.A.</dc:creator> <dc:subject>Flexibilidad</dc:subject> <dc:description>Definir de un modo comprensible para el alumnado la flexibilidad. Mostrar diferentes ejercicios para trabajar la flexibilidad.</dc:description> <dc:publisher>catalogado y financiado con fondos FEDER dentro del expediente 502/06-Lote1</dc:publisher> <dc:contributor/> <dc:date>2008-06-13</dc:date> <dc:type>self assessment</dc:type> <dc:format>text/html</dc:format> <dc:identifier>http://redes.agrega.indra.es/buscador/DetallarODECU/DetallarODECU.do?idioma=es&identificadorODE=es_20071116_2_0162001</dc:identifier> <dc:source>es_20071116_3_0162000</dc:source> <dc:language>es</dc:language> <dc:relation>ispartof</dc:relation> <dc:coverage>Universal</dc:coverage> <dc:rights>creative commons: attribution - non commercial - share alike</dc:rights> </oai_dc:dc> </metadata> </record> <record> <header> <identifier>oai:agrega.es:es_20071116_2_0162001</identifier> <datestamp>2008-06-13</datestamp> </header> <metadata> <oai_dc:dc> <dc:title>agrega : Flexibilidad</dc:title> <dc:creator>Eptron Multimedia S.A.</dc:creator> <dc:subject>Flexibilidad</dc:subject> <dc:description>Definir de un modo comprensible para el alumnado la flexibilidad. Mostrar diferentes ejercicios para trabajar la flexibilidad.</dc:description> <dc:publisher>catalogado y financiado con fondos FEDER dentro del

197

expediente 502/06-Lote1</dc:publisher> <dc:contributor/> <dc:date>2008-06-13</dc:date> <dc:type>self assessment</dc:type> <dc:format>text/html</dc:format> <dc:identifier>http://redes.agrega.indra.es/buscador/DetallarODECU/DetallarODECU.do?idioma=es&identificadorODE=es_20071116_2_0162001</dc:identifier> <dc:source>es_20071116_3_0162000</dc:source> <dc:language>es</dc:language> <dc:relation>ispartof</dc:relation> <dc:coverage>Universal</dc:coverage> <dc:rights>creative commons: attribution - non commercial - share alike</dc:rights> </oai_dc:dc> </metadata> </record> <record> <header> <identifier>oai:agrega.es:es_20071116_2_0162001</identifier> <datestamp>2008-06-13</datestamp> </header> <metadata> <oai_dc:dc> <dc:title>agrega : Flexibilidad</dc:title> <dc:creator>Eptron Multimedia S.A.</dc:creator> <dc:subject>Flexibilidad</dc:subject> <dc:description>Definir de un modo comprensible para el alumnado la flexibilidad. Mostrar diferentes ejercicios para trabajar la flexibilidad.</dc:description> <dc:publisher>catalogado y financiado con fondos FEDER dentro del expediente 502/06-Lote1</dc:publisher> <dc:contributor/> <dc:date>2008-06-13</dc:date> <dc:type>self assessment</dc:type> <dc:format>text/html</dc:format> <dc:identifier>http://redes.agrega.indra.es/buscador/DetallarODECU/DetallarODECU.do?idioma=es&identificadorODE=es_20071116_2_0162001</dc:identifier> <dc:source>es_20071116_3_0162000</dc:source> <dc:language>es</dc:language> <dc:relation>ispartof</dc:relation> <dc:coverage>Universal</dc:coverage> <dc:rights>creative commons: attribution - non commercial - share alike</dc:rights> </oai_dc:dc> </metadata> </record> <record> <header> <identifier>oai:agrega.es:es_20071116_2_0162001</identifier> <datestamp>2008-06-13</datestamp> </header> <metadata> <oai_dc:dc> <dc:title>agrega : Flexibilidad</dc:title> <dc:creator>Eptron Multimedia S.A.</dc:creator> <dc:subject>Flexibilidad</dc:subject> <dc:description>Definir de un modo comprensible para el alumnado la

198

flexibilidad. Mostrar diferentes ejercicios para trabajar la flexibilidad.</dc:description> <dc:publisher>catalogado y financiado con fondos FEDER dentro del expediente 502/06-Lote1</dc:publisher> <dc:contributor/> <dc:date>2008-06-13</dc:date> <dc:type>self assessment</dc:type> <dc:format>text/html</dc:format> <dc:identifier>http://redes.agrega.indra.es/buscador/DetallarODECU/DetallarODECU.do?idioma=es&identificadorODE=es_20071116_2_0162001</dc:identifier> <dc:source>es_20071116_3_0162000</dc:source> <dc:language>es</dc:language> <dc:relation>ispartof</dc:relation> <dc:coverage>Universal</dc:coverage> <dc:rights>creative commons: attribution - non commercial - share alike</dc:rights> </oai_dc:dc> </metadata> </record> <record> <header> <identifier>oai:agrega.es:es_20071116_2_0162001</identifier> <datestamp>2008-06-13</datestamp> </header> <metadata> <oai_dc:dc> <dc:title>agrega : Flexibilidad</dc:title> <dc:creator>Eptron Multimedia S.A.</dc:creator> <dc:subject>Flexibilidad</dc:subject> <dc:description>Definir de un modo comprensible para el alumnado la flexibilidad. Mostrar diferentes ejercicios para trabajar la flexibilidad.</dc:description> <dc:publisher>catalogado y financiado con fondos FEDER dentro del expediente 502/06-Lote1</dc:publisher> <dc:contributor/> <dc:date>2008-06-13</dc:date> <dc:type>self assessment</dc:type> <dc:format>text/html</dc:format> <dc:identifier>http://redes.agrega.indra.es/buscador/DetallarODECU/DetallarODECU.do?idioma=es&identificadorODE=es_20071116_2_0162001</dc:identifier> <dc:source>es_20071116_3_0162000</dc:source> <dc:language>es</dc:language> <dc:relation>ispartof</dc:relation> <dc:coverage>Universal</dc:coverage> <dc:rights>creative commons: attribution - non commercial - share alike</dc:rights> </oai_dc:dc> </metadata> </record> <record> <header> <identifier>oai:agrega.es:es_20071116_2_0162001</identifier> <datestamp>2008-06-13</datestamp> </header> <metadata> <oai_dc:dc> <dc:title>agrega : Flexibilidad</dc:title> <dc:creator>Eptron Multimedia S.A.</dc:creator>

199

<dc:subject>Flexibilidad</dc:subject> <dc:description>Definir de un modo comprensible para el alumnado la flexibilidad. Mostrar diferentes ejercicios para trabajar la flexibilidad.</dc:description> <dc:publisher>catalogado y financiado con fondos FEDER dentro del expediente 502/06-Lote1</dc:publisher> <dc:contributor/> <dc:date>2008-06-13</dc:date> <dc:type>self assessment</dc:type> <dc:format>text/html</dc:format> <dc:identifier>http://redes.agrega.indra.es/buscador/DetallarODECU/DetallarODECU.do?idioma=es&identificadorODE=es_20071116_2_0162001</dc:identifier> <dc:source>es_20071116_3_0162000</dc:source> <dc:language>es</dc:language> <dc:relation>ispartof</dc:relation> <dc:coverage>Universal</dc:coverage> <dc:rights>creative commons: attribution - non commercial - share alike</dc:rights> </oai_dc:dc> </metadata> </record> <record> <header> <identifier>oai:agrega.es:es_20071116_2_0162001</identifier> <datestamp>2008-06-13</datestamp> </header> <metadata> <oai_dc:dc> <dc:title>agrega : Flexibilidad</dc:title> <dc:creator>Eptron Multimedia S.A.</dc:creator> <dc:subject>Flexibilidad</dc:subject> <dc:description>Definir de un modo comprensible para el alumnado la flexibilidad. Mostrar diferentes ejercicios para trabajar la flexibilidad.</dc:description> <dc:publisher>catalogado y financiado con fondos FEDER dentro del expediente 502/06-Lote1</dc:publisher> <dc:contributor/> <dc:date>2008-06-13</dc:date> <dc:type>self assessment</dc:type> <dc:format>text/html</dc:format> <dc:identifier>http://redes.agrega.indra.es/buscador/DetallarODECU/DetallarODECU.do?idioma=es&identificadorODE=es_20071116_2_0162001</dc:identifier> <dc:source>es_20071116_3_0162000</dc:source> <dc:language>es</dc:language> <dc:relation>ispartof</dc:relation> <dc:coverage>Universal</dc:coverage> <dc:rights>creative commons: attribution - non commercial - share alike</dc:rights> </oai_dc:dc> </metadata> </record> <record> <header> <identifier>oai:agrega.es:es_20071116_2_0162001</identifier> <datestamp>2008-06-13</datestamp> </header> <metadata> <oai_dc:dc>

200

<dc:title>agrega : Flexibilidad</dc:title> <dc:creator>Eptron Multimedia S.A.</dc:creator> <dc:subject>Flexibilidad</dc:subject> <dc:description>Definir de un modo comprensible para el alumnado la flexibilidad. Mostrar diferentes ejercicios para trabajar la flexibilidad.</dc:description> <dc:publisher>catalogado y financiado con fondos FEDER dentro del expediente 502/06-Lote1</dc:publisher> <dc:contributor/> <dc:date>2008-06-13</dc:date> <dc:type>self assessment</dc:type> <dc:format>text/html</dc:format> <dc:identifier>http://redes.agrega.indra.es/buscador/DetallarODECU/DetallarODECU.do?idioma=es&identificadorODE=es_20071116_2_0162001</dc:identifier> <dc:source>es_20071116_3_0162000</dc:source> <dc:language>es</dc:language> <dc:relation>ispartof</dc:relation> <dc:coverage>Universal</dc:coverage> <dc:rights>creative commons: attribution - non commercial - share alike</dc:rights> </oai_dc:dc> </metadata> </record> <record> <header> <identifier>oai:agrega.es:es_20071116_2_0162001</identifier> <datestamp>2008-06-13</datestamp> </header> <metadata> <oai_dc:dc> <dc:title>agrega : Flexibilidad</dc:title> <dc:creator>Eptron Multimedia S.A.</dc:creator> <dc:subject>Flexibilidad</dc:subject> <dc:description>Definir de un modo comprensible para el alumnado la flexibilidad. Mostrar diferentes ejercicios para trabajar la flexibilidad.</dc:description> <dc:publisher>catalogado y financiado con fondos FEDER dentro del expediente 502/06-Lote1</dc:publisher> <dc:contributor/> <dc:date>2008-06-13</dc:date> <dc:type>self assessment</dc:type> <dc:format>text/html</dc:format> <dc:identifier>http://redes.agrega.indra.es/buscador/DetallarODECU/DetallarODECU.do?idioma=es&identificadorODE=es_20071116_2_0162001</dc:identifier> <dc:source>es_20071116_3_0162000</dc:source> <dc:language>es</dc:language> <dc:relation>ispartof</dc:relation> <dc:coverage>Universal</dc:coverage> <dc:rights>creative commons: attribution - non commercial - share alike</dc:rights> </oai_dc:dc> </metadata> </record> <resumptionToken expirationDate="2008-06-19T19:48:48.349+02:00" completeListSize="255" cursor="0">1213897728309</resumptionToken> </ListRecords> </OAI-PMH>

201

3.7. Errores A continuación, se detallan algunos de los mensajes de error que puede devolver el repositorio Agrega. Al igual que ocurre con las respuestas correctas éstos serán xml codificados en UTF-8. 3.7.1. BadVerb Mensaje de error que indica que el parámetro verb no es correcto. <?xml version="1.0" encoding="UTF-8"?> <OAI-PMH xmlns="http://www.openarchives.org/OAI/2.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd"> <responseDate>2008-06-20T14:18:09.942+02:00</responseDate> <request>http://redes.agrega.indra.es/oaipmh/OaiPmhRequest/OaiPmhRequest.do</request> <error code="badVerb">El argumento verb es incorrecto</error> </OAI-PMH> 3.7.2. BadArgument Indica que algunos de los parámetros de la petición no son correctos o falta alguno obligatorio. <?xml version="1.0" encoding="UTF-8"?> <OAI-PMH xmlns="http://www.openarchives.org/OAI/2.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd"> <responseDate>2008-06-20T14:18:39.294+02:00</responseDate> <request verb="ListIdentifiers">http://redes.agrega.indra.es/oaipmh/OaiPmhRequest/OaiPmhRequest.do</request> <error code="badArgument">La llamada incluye un parámetro incorrecto o no incluye un argumento obligatorio</error> </OAI-PMH> 3.7.3. CannotDisseminateFormat Mensaje de error que indica que el tipo de metadato no esta soportado por la plataforma. <?xml version="1.0" encoding="UTF-8"?> <OAI-PMH xmlns="http://www.openarchives.org/OAI/2.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd"> <responseDate>2008-06-20T14:18:57.709+02:00</responseDate> <request verb="ListIdentifiers" metadataPrefix="oai_d">http://redes.agrega.indra.es/oaipmh/OaiPmhRequest/OaiPmhRequest.do</request>

202

<error code="cannotDisseminateFormat">Tipo de metadato no soportado en la plataforma</error> </OAI-PMH> 3.7.4. idDoesNotExist Indica que el identificador del registro no se existe en la plataforma. <?xml version="1.0" encoding="UTF-8"?> <OAI-PMH xmlns="http://www.openarchives.org/OAI/2.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd"> <responseDate>2008-06-20T14:20:29.974+02:00</responseDate> <request verb="GetRecord" identifier="asdfsdf" metadataPrefix="oai_dc">http://redes.agrega.indra.es/oaipmh/OaiPmhRequest/OaiPmhRequest.do</request> <error code="idDoesNotExist">El identificador no existe en la plataforma</error> </OAI-PMH>


30 min


4. Gestor de sesiones El gestor de sesiones es un módulo de Agrega que permite a los servicios externos interaccionar con los módulos ofrecidos a través del interfaz Web Service donde se requiere un identificador de sesión. Esta funcionalidad permite a la plataforma establecer un interfaz de control mínimo a los servicios externos que interaccionan con los interfaces WS’s públicos de Agrega. Los interfaces WS’s que están relacionados con el servicio de gestión de sesiones en la plataforma son el interfaz DRI y el SQI en los que el concepto de sesión esta presente en las cabeceras de sus métodos. Desde la funcionalidad del gestor de sesiones se implementan funcionalidades básicas como son:

• crear sesión: crear una sesión válida dentro del sistema. • crear sesión anónima: crear una sesión anónima dentro de sistema. • eliminar sesión: eliminar una sesión válida dentro del sistema.

203

4.1. Alcance El módulo de gestión de sesiones esta concebido para la interacción con el sistema Agrega dentro de las funcionalidades DRI y SQI expuestas mediante Web Services. El concepto de sesión se establece como paso previo para la interacción con estos dos servicios. En el interfaz se define la creación de sesiones autenticadas y sesiones anónimas para las que no hay necesidad de ser un usuario dado de alta en el sistema. La funcionalidad del servicio de sesiones se ha realizado a través del intercambio de mensajes SOAP sobre el protocolo HTTP. La interacción con el servicio de sesiones se puede realizar partiendo del documento WSDL, que describe el funcionamiento y los detalles de invocación del módulo y que permite a cualquier potencial usuario la creación de un cliente SOAP capaz de enviar mensajes SOAP al módulo de sesiones. 4.2. Integración a través de WebServices A continuación, se describen con detalle todos los métodos implementados en el API del gestor de sesiones así como la descripción de los parámetros necesarios para su correcta invocación, los tipos de información devuelta y los errores posibles. 4.2.1. createSession Definición del método El método tiene el siguiente aspecto:

CreateSession (String userId, String password) throws Exception

Este método requiere como parámetros un identificador de usuario y la clave asociada al mismo. Tanto el usuario como la clave deben estar dados de alta en la plataforma para tener acceso a un identificador válido. En el caso de que esto sea así, el método devuelve un identificador de sesión válido con el que poder interaccionar con la plataforma. Ejemplo A continuación, se añade un ejemplo de llamada y de respuesta: Ejemplo 01: llamada al método CreateSession enviando un usuario y clave. Llamada: <?xml version="1.0" encoding="UTF-8" ?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <createSession xmlns="http://Sesion.servicios.negocio.dri.pode.es"> <userID>admincatalogador</userID> <password>admincatalogador</password> </createSession>

204

</soapenv:Body> </soapenv:Envelope> Respuesta: se obtiene como respuesta identificador de sesión válido. <?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <createSessionResponse xmlns="http://Sesion.servicios.negocio.dri.pode.es"> <createSessionReturn>ff8080811ad87512011ad8a4084d0002</createSessionReturn> </createSessionResponse> </soapenv:Body> </soapenv:Envelope> 4.2.2. createAnonymousSession Definición del método El método tiene el siguiente aspecto:

CreateAnonymousSession () throws Exception

Este método no requiere parámetros y devuelve un identificador de sesión válido con el que poder interaccionar con la plataforma. Ejemplo A continuación, se añade un ejemplo de llamada y de respuesta: Ejemplo 01: llamada al método CreateAnonymousSession. Llamada: <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <SOAP-ENV:Body> <m:createAnonymousSession xmlns:m="http://Sesion.servicios.negocio.dri.pode.es"/> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Respuesta: se obtiene como respuesta identificador de sesión válido. <?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <createAnonymousSessionResponse

205

xmlns="http://Sesion.servicios.negocio.dri.pode.es"> <createAnonymousSessionReturn>ff8080811ad87512011ad8a4c2220003</createAnonymousSessionReturn> </createAnonymousSessionResponse> </soapenv:Body> </soapenv:Envelope> 4.2.3. destroySession Definición del método El método tiene el siguiente aspecto:

DestroySession (String sessionID) throws Exception

Este método toma como parámetro el identificador de la sesión que se quiere eliminar. El resultado de esta operación es la eliminación del sistema de gestión de sesiones de la sesión a la que corresponde el identificador. Ejemplo A continuación se añade un ejemplo de llamada y de respuesta: Ejemplo 01: llamada al método DestroySession. Llamada: <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <SOAP-ENV:Body> <m:destroySession xmlns:m="http://Sesion.servicios.negocio.dri.pode.es"> <m:sessionID>ff8080811ad87512011ad8a4c2220003</m:sessionID> </m:destroySession> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Respuesta: no hay respuesta a esta llamada. <?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <destroySessionResponse xmlns="http://Sesion.servicios.negocio.dri.pode.es"/> </soapenv:Body> </soapenv:Envelope>


206

1 h


5. SQI SQI son las siglas de “Simple Query Interface”. Se trata de una especificación, enmarcada en el entorno de los repositorios de objetos de aprendizaje, que define una capa para facilitar las búsquedas. Pretende especificar un estándar para resolver la problemática de las búsquedas de contenidos digitales en entornos heterogéneos. El interfaz SQI define un API con las siguientes funcionalidades:

• set query language: se define el lenguaje con el que se escribe la consulta con la que se va a realizar la búsqueda. El lenguaje de consulta esta definido por el repositorio sobre el que se realiza la búsqueda.

• set results format: se especifica el lenguaje en el que se va a generar la respuesta a la consulta.

• set max query results: se definen el máximo número de resultados que una consulta puede producir.

• set max duration: establece un tiempo máximo de duración para las consultas asíncronas.

• set results set size: establece un tamaño máximo del conjunto de resultados que se devuelve como resultado de una búsqueda.

• sychronous query: ejecuta la consulta sobre el repositorio. • get total results count: devuelve el número total de resultados que

produce una consulta sobre un repositorio. • asynchronous query: ejecuta la consulta sobre el repositorio pero de una

forma asíncrona. • set source location: establece la localización sobre la que el repositorio

tiene que devolver los resultados de consulta en el caso de ser invocado de forma asíncrona.

• query results listener. 5.1. Alcance En la plataforma agrega se ha implementado el servicio de SQI siguiendo las especificaciones del documento CWA 15454 que define con detalle todas las cabeceras, nombres de parámetros, sintaxis, funcionalidad y tipos de datos del API SQI. En dicho documento se hace referencia a la necesidad del desarrollo en paralelo (y alejado del alcance del estándar) de un servicio de sesiones básico a través del cual, el servicio cliente de SQI interacciona con el repositorio de objetos digitales. En Agrega, el servicio de gestión de sesiones se hace cargo de este papel y hace de árbitro entre los clientes SQI y la plataforma. La implementación del interfaz SQI en Agrega admite los lenguajes de consulta VSQI LQS, mientras que el lenguaje en el que se muestran las respuestas es LOM-ES. El interfaz de consultas esta implementado para la realización de consultas síncronas. La implementación del interfaz de SQI se ha realizado a través del

207

intercambio de mensajes SOAP sobre el protocolo HTTP. La interacción con el servicio de SQI se puede realizar partiendo del documento WSDL, que describe el funcionamiento y los detalles de invocación del módulo y que permite a cualquier potencial servicio cliente la creación de un cliente SOAP capaz de enviar mensajes SOAP al módulo de SQI. 5.2. Integración a través de WebServices A continuación, se describen con detalle todos los métodos implementados en el API del servicio de SQI así como la descripción de los parámetros necesarios para su correcta invocación, los tipos de información devuelta y los errores posibles. 5.2.1. getTotalResultsCount Definición del método El método tiene el siguiente aspecto:

GetTotalResultsCount (String targetSessionID, String queryStatement) throws Exception

Este método requiere como parámetros un identificador de sesión y un texto con una consulta. El identificador de sesión debe pertenecer a una sesión válida y la consulta estar escrita en un lenguaje aceptado por la plataforma. En el caso de que esto sea así, el método devuelve el número total de resultados disponibles para la consulta suministrada. En el caso de que ocurra algún problema, se devuelve una excepción con el detalle de lo ocurrido: identificador de sesión inválido, lenguaje de la consulta no soportado, consulta no soportada o cualquier otro error no contemplado. Ejemplo A continuación se añade un ejemplo de llamada y de respuesta: Ejemplo 01: llamada al método GetTotalResultsCount enviando un identificador de sesión y un texto de búsqueda. Llamada: <?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body><getTotalResultsCount xmlns="urn:www.cenorm.be/isss/ltws/wsdl/SQIv1p0"><targetSessionID>ff8080811ada0473011ada6c636b0004</targetSessionID><queryStatement><simpleQuery><term>estrellas</term></simpleQuery></queryStatement></getTotalResultsCount></soapenv:Body></soapenv:Envelope> Respuesta: se obtiene como respuesta el número de resultados que ha producido la consulta.

208

<?xml version="1.0" encoding="utf-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body><getTotalResultsCountResponse xmlns="urn:www.cenorm.be/isss/ltws/wsdl/SQIv1p0"><getTotalResultsCountReturn>1</getTotalResultsCountReturn></getTotalResultsCountResponse></soapenv:Body></soapenv:Envelope> 5.2.2. setMaxDuration Definición del método El método tiene el siguiente aspecto:

SetMaxDuration (String targetSessionID, Integer maxDuration) throws Exception

Este método requiere como parámetros un identificador de sesión y un número de entero positivo. El identificador de sesión debe pertenecer a una sesión válida y la cifra se interpreta como milisegundos. En el caso de que esto sea así, el método configura la máxima duración de una consulta asíncrona con el número de milisegundos que se pasan. En el caso de que ocurra algún problema, se devuelve una excepción con el detalle de lo ocurrido: identificador de sesión inválido, número de milisegundos inválido o cualquier otro error no contemplado. Ejemplo A continuación, se añade un ejemplo de llamada y de respuesta: Ejemplo 01: llamada al método SetMaxDuration enviando un identificador de sesión y número de milisegundos. Llamada: <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <SOAP-ENV:Body> <m:setMaxDuration xmlns:m="http://SQI.servicios.negocio.dri.pode.es"> <m:targetSessionID>ff8080811ada0473011ada465ad10001</m:targetSessionID> <m:maxDuration>123456789</m:maxDuration> </m:setMaxDuration> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Respuesta: este método no devuelve ningún dato.

209

<?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <setMaxDurationResponse xmlns="http://SQI.servicios.negocio.dri.pode.es"/> </soapenv:Body> </soapenv:Envelope> 5.2.3. setResultsFormat Definición del método El método tiene el siguiente aspecto:

SetResultsFormat (String targetSessionID, String resultsFormat) throws Exception

Este método requiere como parámetros un identificador de sesión y el identificador de un lenguaje de respuesta de resultados de búsqueda. El identificador de sesión debe pertenecer a una sesión válida y el lenguaje, a un lenguaje admitido por la plataforma (en este caso, LOM-ES). En el caso de que esto sea así, el método configura el lenguaje de los resultados de búsqueda. En el caso de que ocurra algún problema, se devuelve una excepción con el detalle de lo ocurrido: identificador de sesión inválido, lenguaje de los resultados de búsqueda no soportado o cualquier otro error no contemplado. Ejemplo A continuación se añade un ejemplo de llamada y de respuesta: Ejemplo 01: llamada al método SetResultsFormat enviando un identificador de sesión y un identificador de lenguaje resultado de búsqueda. Llamada: <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <SOAP-ENV:Body> <m:setResultsFormat xmlns:m="http://SQI.servicios.negocio.dri.pode.es"> <m:targetSessionID>ff8080811ada0473011ada465ad10001</m:targetSessionID> <m:resultsFormat>LOM-ES</m:resultsFormat> </m:setResultsFormat> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Respuesta: este método no devuelve ningún dato.

210

<?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <setResultsFormatResponse xmlns="http://SQI.servicios.negocio.dri.pode.es"/> </soapenv:Body> </soapenv:Envelope> 5.2.4. setResultSetSize Definición del método El método tiene el siguiente aspecto:

SetResultSetSize (String targetSessionID, Integer resultSetSize) throws Exception

Este método requiere como parámetros un identificador de sesión y una cifra con el tamaño del conjunto de elementos devueltos. El identificador de sesión debe pertenecer a una sesión válida y el tamaño del conjunto de resultados ser válido. En el caso de que esto sea así, el método configura el tamaño del conjunto de resultados de búsqueda. En el caso de que ocurra algún problema, se devuelve una excepción con el detalle de lo ocurrido: identificador de sesión inválido, tamaño de conjunto de resultados inválido o cualquier otro error no contemplado. Ejemplo A continuación, se añade un ejemplo de llamada y de respuesta: Ejemplo 01: llamada al método SetResultSetSize enviando un identificador de sesión y un tamaño de conjunto de resultados. Llamada: <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <SOAP-ENV:Body> <m:setResultsSetSize xmlns:m="http://SQI.servicios.negocio.dri.pode.es"> <m:targetSessionID>ff8080811ada0473011ada5c5b9b0002</m:targetSessionID> <m:resultsSetSize>100</m:resultsSetSize> </m:setResultsSetSize> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Respuesta: este método no devuelve ningún dato.

211

<?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <setResultsSetSizeResponse xmlns="http://SQI.servicios.negocio.dri.pode.es"/> </soapenv:Body> </soapenv:Envelope> 5.2.5. setQueryLanguage Definición del método El método tiene el siguiente aspecto:

SetQueryLamguage (String targetSessionID, String queryLanguajeID) throws Exception

Este método requiere como parámetros un identificador de sesión y un identificador de lenguaje de consulta. El identificador de sesión debe pertenecer a una sesión válida y el identificador de lenguaje deberá estar entre los identificadores de lenguajes de consulta aceptados por Agrega (VSQI, LQS). En el caso de que esto sea así, el método configura el lenguaje de consultas de las búsquedas. En el caso de que ocurra algún problema, se devuelve una excepción con el detalle de lo ocurrido: identificador de sesión inválido, lenguaje de consulta no soportado u otro error no contemplado. Ejemplo A continuación se añade un ejemplo de llamada y de respuesta: Ejemplo 01: llamada al método SetQueryLamguage enviando un identificador de sesión y un identificador de lenguaje de consulta. Llamada: <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <SOAP-ENV:Body> <m:setQueryLanguage xmlns:m="http://SQI.servicios.negocio.dri.pode.es"> <m:targetSessionID>ff8080811ada0473011ada62b4b50003</m:targetSessionID> <m:queryLanguageID>VSQI</m:queryLanguageID> </m:setQueryLanguage> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Respuesta: este método no devuelve ningún dato.

212

<?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <setQueryLanguageResponse xmlns="http://SQI.servicios.negocio.dri.pode.es"/> </soapenv:Body> </soapenv:Envelope> 5.2.6. setMaxQueryResults Definición del método El método tiene el siguiente aspecto:

SetMaxQueryResults (String targetSessionID, Integer maxQueryResults) throws Exception

Este método requiere como parámetros un identificador de sesión y un entero con el máximo número de resultados que una búsqueda puede producir. El identificador de sesión debe pertenecer a una sesión válida y el entero deberá ser una cifra válida de resultados de una búsqueda. En el caso de que esto sea así, el método configura el máximo número de resultados de una búsqueda. En el caso de que ocurra algún problema, se devuelve una excepción con el detalle de lo ocurrido: identificador de sesión inválido, número de máximo número de resultados inválido u otro error no contemplado. Ejemplo A continuación se añade un ejemplo de llamada y de respuesta: Ejemplo 01: llamada al método SetMaxQueryResults enviando un identificador de sesión y un identificador de lenguaje de consulta. Llamada: <?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body><setMaxQueryResults xmlns="urn:www.cenorm.be/isss/ltws/wsdl/SQIv1p0"><targetSessionID>ff8080811ada0473011ada6c636b0004</targetSessionID><maxQueryResults>10000</maxQueryResults></setMaxQueryResults></soapenv:Body></soapenv:Envelope> Respuesta: este método no devuelve ningún dato. <?xml version="1.0" encoding="utf-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body><setMaxQueryResultsResponse

213

e> 5.2.7. synchronousQuery Definición del método El método tiene el siguiente aspecto:

SynchronousQuery (String targetSessionID, String queryStatement, Integer startResult) throws Exception

Este método requiere como parámetros un identificador de sesión, una sentencia con el texto de la consulta y un valor entero que indica el índice del primer resultado sobre el total posible a partir del cual se quieren elementos devueltos. El identificador de sesión debe pertenecer a una sesión válida, la sentencia debe estar escrita en un lenguaje admitido por la plataforma Agrega y el valor del índice sobre el total de resultados. En el caso de que esto sea así, el método realiza una consulta sobre el repositorio de objetos digitales de Agrega con la consulta suministrada de forma síncrona, y devolviendo un conjunto de resultados indexados respecto del total de hits por el identificador suministrado. En el caso de que ocurra algún problema, se devuelve una excepción con el detalle de lo ocurrido: identificador de sesión inválido, modo de invocación no soportado, tamaño inválido del conjunto de resultados, sentencia de consulta inválida u otro error no contemplado. Ejemplo A continuación se añade un ejemplo de llamada y de respuesta: Ejemplo 01: llamada al método SynchronousQuery enviando un identificador de sesión un texto de búsqueda y un identificador de resultados. Llamada: <?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body><synchronousQuery xmlns="urn:www.cenorm.be/isss/ltws/wsdl/SQIv1p0"><targetSessionID>ff8080811ada0473011ada6c636b0004</targetSessionID><queryStatement><simpleQuery><term>estrellas</term></simpleQuery></queryStatement><startResult>1</startResult></synchronousQuery></soapenv:Body></soapenv:Envelope> Respuesta: este método devuelve los metadatos de los contenidos digitales que ajustan con la consulta suministrada. <?xml version="1.0" encoding="utf-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body><synchronousQueryResponse xmlns="urn:www.cenorm.be/isss/ltws/wsdl/SQIv1p0"><synchronousQueryReturn><?xml

214

version="1.0" encoding="UTF-8"?> <lom xmlns="http://ltsc.ieee.org/xsd/LOM"><general uniqueElementName="general"><identifier uniqueElementName="identifier"><catalog uniqueElementName="catalog">Catálogo unificado mec-red.es-ccaa de identificación de ODE</catalog><entry uniqueElementName="entry">es_20080630_1_9135401</entry&g t;</identifier><identifier …….contenido del LOM/ES…….. </synchronousQueryReturn></synchronousQueryResponse></soapenv:Body></soapenv:Envelope>


30 min


6. DRI DRI son las siglas de “Digital Repositories Interoperability”. Se trata de una especificación (nacida dentro del IMS Consortium) que se define dentro del contexto de los repositorios de contenidos digitales para facilitar su interoperabilidad. Según la especificación DRI, la interacción de los repositorios se consigue mediante la implementación de una serie de funcionalidades consideradas básicas en cualquier repositorio:

• Búsqueda: Se define como el interfaz a través del cual poder realizar búsquedas sobre los metadatos de los contenidos almacenados en los repositorios.

• Exposición: Se define como el interfaz sobre el que poder solicitar los metadatos de los recursos almacenados.

• Almacenamiento: Se trata de la definición de la forma en la que un recurso se puede introducir en un repositorio y de cómo se representará dentro del mismo para su posterior acceso.

• Entrega: Define la forma en que un repositorio puede entregar contenidos. 6.1. Alcance De todas las funcionalidades básicas que especifica el estándar, se han implementado en el módulo de DRI de la plataforma Agrega las funciones de almacenar y entregar a través de los métodos presentar-almacenar, presentar-catalogar y solicitar-entregar.

• presentar-almacenar: admite la publicación dentro de la plataforma de objetos externos.

• presentar-catalogar: admite objetos externos y los deja en un estado pendiente de catalogación, paso previo dentro de Agrega a la publicación.

215

• solicitar-entregar: se devuelve un objeto digital publicado dentro de la plataforma.

La implementación del estándar se ha realizado a través del intercambio de mensajes SOAP sobre el protocolo HTTP. De esta forma se ha implementado una arquitectura de servicio con tecnología Web Services que facilita el intercambio de información entre potenciales clientes del repositorio y la plataforma y que encaja dentro del diagrama de proveedores de servicio y servicios de acceso definidos en la especificación del IMS Consortium. El Web Service que implementa esta funcionalidad trabaja en consonancia con otro servicio de gestión de sesiones. Este servicio facilita la gestión del control de acceso a los contenidos digitales de la plataforma mediante un sencillo mecanismo de autenticación. De esta forma, tanto el almacenamiento de nuevos contenidos como la entrega de información del repositorio están expuestos de forma pública, pero supeditados a un control de acceso. La invocación de los tres métodos se puede realizar mediante el uso de un identificador de sesión (previa creación de una sesión contra el servicio de gestión de sesiones) o mediante el suministro de un identificador de usuario con su correspondiente clave. Dicho usuario debe ser un usuario válido dentro del sistema La interacción con el interfaz DRI se puede realizar partiendo del documento WSDL, que describe el funcionamiento y los detalles de invocación del módulo y que permite a cualquier potencial usuario la creación de un cliente SOAP capaz de enviar mensajes SOAP al módulo de DRI. 6.2. Integración a través de WebServices A continuación, se describen en detalle todos los métodos implementados en el API de DRI así como la descripción de los parámetros necesarios para su correcta invocación, los tipos de información devuelta y los errores posibles. 6.2.1. presentarAlmacenarSesion Definición del método El método tiene el siguiente aspecto:

PresentarAlmacenarSesion (String sesionId, DataHandler pif) throws Exception

Este método necesita como parámetro un identificador de sesión válido y el fichero que contiene el ODE que se pretende almacenar en formato Pif. El resultado de la operación es la publicación dentro de la plataforma del ODE suministrado. Ejemplo A continuación, se añade un ejemplo de llamada y de respuesta: Ejemplo 01: llamada al método PresentarAlmacenarSesion enviando un ODE. Llamada:

216

<?xml version="1.0" encoding="UTF-8" ?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <presentarAlmacenarSesion xmlns="http://DRI.servicios.negocio.dri.pode.es"> <sesionId>ff8080811ad87512011ad8a4084d0002</sesionId> <pif href="cid:AFEBB0E5BCC89E61E1B43FF563BC0BC9" /> </presentarAlmacenarSesion> </soapenv:Body> </soapenv:Envelope> ------=_Part_2_4835957.1214824149296 Content-Type: application/octet-stream Content-Transfer-Encoding: binary Content-Id: <C0362C12E70D7B0BD27042C2996704B9> {…. contenido binario del DataHandler…} ------=_Part_2_4835957.1214824149296-- Respuesta: se obtiene como respuesta un mensaje SOAP conteniendo la información devuelta por el método. <?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body><presentarAlmacenarSesionResponse xmlns="http://DRI.servicios.negocio.dri.pode.es"/></soapenv:Body></soapenv:Envelope> 6.2.2. presentarAlmacenar Definición del método El método tiene el siguiente aspecto:

PresentarAlmacenar (String usuario, String clave, DataHandler pif) throws Exception

Este método necesita como parámetro un usuario válido, su clave dentro del sistema y el fichero que contiene el ODE que se pretende almacenar en formato Pif. El resultado de la operación es la publicación dentro de la plataforma del ODE suministrado. Ejemplo A continuación se añade un ejemplo de llamada y de respuesta: Ejemplo 01: llamada al método PresentarAlmacenar enviando un ODE. Llamada

217

<?xml version="1.0" encoding="UTF-8" ?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <presentarAlmacenar xmlns="http://DRI.servicios.negocio.dri.pode.es"> <sesionId>ff8080811ad87512011ad8a4084d0002</sesionId> <pif href="cid:AFEBB0E5BCC89E61E1B43FF563BC0BC8" /> </presentarAlmacenar> </soapenv:Body> </soapenv:Envelope> ------=_Part_2_4835957.1214824149297 Content-Type: application/octet-stream Content-Transfer-Encoding: binary Content-Id: <C0362C12E70D7B0BD27042C2996704B8> {…. contenido binario del DataHandler…} ------=_Part_2_4835957.1214824149297-- Respuesta: se obtiene como respuesta un mensaje SOAP conteniendo la información devuelta por el método. <?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body><presentarAlmacenarResponse xmlns="http://DRI.servicios.negocio.dri.pode.es"/></soapenv:Body></soapenv:Envelope> 6.2.3. SolicitarEntregarSesion Definición del método El método tiene el siguiente aspecto:

SolicitarEntregarSesion (String sesionId, String mec) throws Exception

Este método necesita un identificador de sesión válida y un identificador de objeto digital que resida publicado en el repositorio. Se devuelve un ODE en formato Pif. Ejemplo A continuación se añade un ejemplo de llamada y de respuesta: Ejemplo 01: llamada al método SolicitarEntregarSesion enviando un mec. Llamada: <?xml version="1.0" encoding="UTF-8" ?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <solicitarEntregarSesion xmlns="http://DRI.servicios.negocio.dri.pode.es"> <sesionId>ff8080811ad92757011ad9275bac0001</sesionId> <mec>es_20070901_3_0261100</mec>

218

</solicitarEntregarSesion> </soapenv:Body> </soapenv:Envelope> Respuesta: se obtiene como respuesta un mensaje SOAP conteniendo la información devuelta por el método. Dentro de la información devuelta se encuentra un adjunto con el fichero del ODE en formato Pif. ------=_Part_1_17172160.1214825271850 Content-Type: text/xml; charset=UTF-8 Content-Transfer-Encoding: binary Content-Id: <DE89AF93EBB40323FBEF9CD025A66BCB> <?xml version="1.0" encoding="utf-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body><solicitarEntregarSesionResponse xmlns="http://DRI.servicios.negocio.dri.pode.es"><solicitarEntregarSesionReturn href="cid:E5DB451354A6BD7465318D4DA6E41C8D"/></solicitarEntregarSesionResponse></soapenv:Body></soapenv:Envelope> ------=_Part_1_17172160.1214825271850 Content-Type: application/octet-stream Content-Transfer-Encoding: binary Content-Id: <E5DB451354A6BD7465318D4DA6E41C8D> {…. contenido binario del DataHandler…} 6.2.4. solicitarEntregar Definición del método El método tiene el siguiente aspecto:

SolicitarEntregar (String usuario, String clave, String mec) throws Exception

Este método necesita un identificador de usuario válido en la plataforma, su clave dentro del sistema y un identificador de objeto digital que resida publicado en el repositorio. Se devuelve un ODE en formato Pif. Ejemplo A continuación, se añade un ejemplo de llamada y de respuesta: Ejemplo 01: llamada al método SolicitarEntregar enviando un mec. Llamada: <?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body><solicitarEntregar xmlns="http://DRI.servicios.negocio.dri.pode.es"><usuario>admincatalogador</usuario><clave>admincatalogador</clave><mec>es_20070901_3_0261100</mec></solicitarEntregar></soapenv:Body></soapenv:Envelope>

219

Respuesta: se obtiene como respuesta un mensaje SOAP conteniendo la información devuelta por el método. Dentro de la información devuelta se encuentra un adjunto con el fichero del ODE en formato Pif. ------=_Part_2_19820335.1214826005924 Content-Type: text/xml; charset=UTF-8 Content-Transfer-Encoding: binary Content-Id: <A995CD42245926228341AF8C6C8A1475> <?xml version="1.0" encoding="utf-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body><solicitarEntregarResponse xmlns="http://DRI.servicios.negocio.dri.pode.es"><solicitarEntregarReturn href="cid:66ACF3BB49B51C3848FC5059ADD0228E"/></solicitarEntregarResponse></soapenv:Body></soapenv:Envelope> ------=_Part_2_19820335.1214826005924 Content-Type: application/octet-stream Content-Transfer-Encoding: binary Content-Id: <66ACF3BB49B51C3848FC5059ADD0228E> {…. contenido binario del DataHandler…} 6.2.5. presentarCatalogarSesion Definición del método El método tiene el siguiente aspecto:

PresentarCatalogarSesion (String sesionId, DataHandler pif) throws Exception

Este método necesita un identificador de sesión válida y un fichero con un ODE válido en formato pif. El resultado de esta operación es la introducción del recurso digital dentro de la plataforma en estado pendiente de catalogación. Ejemplo A continuación, se añade un ejemplo de llamada y de respuesta: Ejemplo 01: llamada al método SolicitarEntregarSesion enviando un ODE. Llamada: <?xml version="1.0" encoding="UTF-8" ?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <presentarCatalogarSesion xmlns="http://DRI.servicios.negocio.dri.pode.es"> <sesionId>ff8080811ad92757011ad9516db60003</sesionId> <pif href="cid:6935E10DBEAC67589B877E24BCDEF3E5" /> </presentarCatalogarSesion> </soapenv:Body> </soapenv:Envelope>

220

------=_Part_5_14808011.1214826931450 Content-Type: application/octet-stream Content-Transfer-Encoding: binary Content-Id: <6935E10DBEAC67589B877E24BCDEF3E5> {…. contenido binario del DataHandler…} ------=_Part_5_14808011.1214826931450-- Respuesta: se obtiene como respuesta un mensaje SOAP conteniendo la información devuelta por el método. <?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body><presentarCatalogarSesionResponse xmlns="http://DRI.servicios.negocio.dri.pode.es"/></soapenv:Body></soapenv:Envelope> 6.2.6. presentarCatalogar Definición del método El método tiene el siguiente aspecto:

PresentarCatalogar (String usuario, String clave, DataHandler pif) throws Exception

Este método necesita un identificador de usuario válido en la plataforma, su clave dentro del sistema y un fichero con un ODE válido en formato pif. El resultado de esta operación es la introducción del recurso digital dentro de la plataforma en estado pendiente de catalogación. Ejemplo A continuación se añade un ejemplo de llamada y de respuesta: Ejemplo 01: llamada al método PresentarCatalogar enviando un ODE. Llamada: <?xml version="1.0" encoding="UTF-8" ?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <presentarCatalogar xmlns="http://DRI.servicios.negocio.dri.pode.es"> <usuario>admincatalogador</usuario> <clave>admincatalogador</clave> <pif href="cid:423B4845FBE2C2B094071BF68336DCBB" /> </presentarCatalogar> </soapenv:Body> </soapenv:Envelope> ------=_Part_5_14808011.1214826931450 Content-Type: application/octet-stream Content-Transfer-Encoding: binary Content-Id: <423B4845FBE2C2B094071BF68336DCBB> {…. contenido binario del DataHandler…}

221

------=_Part_5_14808011.1214826931450-- Respuesta: se obtiene como respuesta un mensaje SOAP conteniendo la información devuelta por el método. <?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body><presentarCatalogarResponse xmlns="http://DRI.servicios.negocio.dri.pode.es"/></soapenv:Body></soapenv:Envelope>


¿Cómo se puede conocer qué servicios publica la plataforma Agrega?

Solicita información sobre el servidor de OAI-PMH. A continuación solicita mediante OAI-PMH una lista de los identificadores de los objetos digitales publicados en el repositorio del nodo.

Recupera mediante OAI-PMH información de un objeto digital publicado en el repositorio del nodo.

222

Referencias Apache 2.X WebServer http://httpd.apache.org/ http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html http://httpd.apache.org/docs/2.0/mod/mod_deflate.html Apache Directory Studio http://directory.apache.org/studio/ Birt http://www.eclipse.org/birt/phoenix/ DRI http://www.imsglobal.org/digitalrepositories/driv1p0/imsdri_infov1p0.html#1256215 FFmpeg http://ffmpeg.mplayerhq.hu/ ImageMagick http://www.imagemagick.org/script/index.php JBoss Application Server http://www.jboss.org/jbossas/ http://wiki.jboss.org/wiki/JBossASTuningSliming https://wiki.jboss.org/wiki/OptimalMod_jk1.2Configuration http://docs.jboss.com/jbossas/guides/clusteringguide/r2/en/html_single/#clustering-http-modjk http://tomcat.apache.org/tomcat-5.5-doc/config/http.html JDK 1.6u6 http://java.sun.com/products/archive/ http://java.sun.com/javase/technologies/hotspot/ http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp http://java.sun.com/developer/technicalArticles/Programming/turbo/ http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html LDAP Browser http://www.mcs.anl.gov/~gawor/ldap/ Lucene http://lucene.apache.org/java/docs/index.html LVM Howto http://tldp.org/HOWTO/LVM-HOWTO/ MediaWiki http://www.mediawiki.org/wiki/MediaWiki Mozilla Firefox http://www.mozilla-europe.org/es/firefox/

http://httpd.apache.org/

http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html

http://httpd.apache.org/docs/2.0/mod/mod_deflate.html

http://directory.apache.org/studio/

http://www.eclipse.org/birt/phoenix/

http://www.imsglobal.org/digitalrepositories/driv1p0/imsdri_infov1p0.html#1256215

http://www.imsglobal.org/digitalrepositories/driv1p0/imsdri_infov1p0.html#1256215

http://ffmpeg.mplayerhq.hu/

http://www.imagemagick.org/script/index.php

http://www.jboss.org/jbossas/

http://wiki.jboss.org/wiki/JBossASTuningSliming

https://wiki.jboss.org/wiki/OptimalMod_jk1.2Configuration

http://docs.jboss.com/jbossas/guides/clusteringguide/r2/en/html_single/#clustering-http-modjk

http://docs.jboss.com/jbossas/guides/clusteringguide/r2/en/html_single/#clustering-http-modjk

http://tomcat.apache.org/tomcat-5.5-doc/config/http.html

http://java.sun.com/products/archive/

http://java.sun.com/javase/technologies/hotspot/

http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp

http://java.sun.com/developer/technicalArticles/Programming/turbo/

http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html

http://www.mcs.anl.gov/%7Egawor/ldap/

http://lucene.apache.org/java/docs/index.html

http://tldp.org/HOWTO/LVM-HOWTO/

http://www.mediawiki.org/wiki/MediaWiki

http://www.mozilla-europe.org/es/firefox/

223

MySQL http://dev.mysql.com/doc/refman/5.0/en/ NFS (Linux NFS Howto) http://nfs.sourceforge.net/nfs-howto/ OAIPMH http://www.openarchives.org http://dublincore.org/ OpenLDAP http://www.openldap.org/ http://www.openldap.org/doc/admin24/slapdconfig.html http://www.openldap.org/doc/admin24/dbtools.html Quartz http://www.opensymphony.com/quartz ReiserFS http://es.wikipedia.org/wiki/ReiserFS SQI ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/WS-LT/cwa15454-00-2005-Nov.pdf SQUID Cache http://www.squid-cache.org/ http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html XFS http://oss.sgi.com/projects/xfs/ Xvfb http://www.xfree86.org/4.0.1/Xvfb.1.html

http://dev.mysql.com/doc/refman/5.0/en/

http://nfs.sourceforge.net/nfs-howto/

http://www.openarchives.org/

http://dublincore.org/

http://www.openldap.org/

http://www.openldap.org/doc/admin24/slapdconfig.html

http://www.openldap.org/doc/admin24/dbtools.html

http://www.opensymphony.com/quartz

http://es.wikipedia.org/wiki/ReiserFS

ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/WS-LT/cwa15454-00-2005-Nov.pdf

http://www.squid-cache.org/

http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html

http://oss.sgi.com/projects/xfs/

http://www.xfree86.org/4.0.1/Xvfb.1.html

Manual para Técnicos

Documents

Transcript of Manual para Técnicos