Manual para Técnicos

Formación para técnicos
Manual del formador

Í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
2
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.
3
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.
4
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 Módulo 3 Módulo 4 Módulo 5 Dudas y

Módulo 1 cierre del
taller
13.00-14.00
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.
5
Secuencia de contenidos Temporalización
Presentación del grupo 10 minutos
Presentación del taller: organización, objetivos a alcanzar,

20 minutos
contenidos, etc.)
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 30 minutos

en los participantes.
6
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.
7
Manual módulo 1
Resumen de funcionalidades
8
Í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
9
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.
10
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.
11
Proyecta las diapositivas 6 a 10.
2h Explicación del contenido
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
12
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.
13
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.
14
• 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.
15
• 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.
16
• 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
17
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.
18
• 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
19
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.
20
Manual módulo 2
Arquitectura
21
Índice
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
22
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.
23
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:
Apache
Capa servidor Web PHP (MediaWiki)
Squid (caché opcional)
JBoss Application Server
Capa de aplicación JDK 1.6
Galería de Imágenes
NFS
Capa de datos 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.
24
1 h 30 min Explicación del contenido
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.
25
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.
26
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:
27
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.
28
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:
29
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
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
DRI
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.
30
o Entregar, con el fin de ofrecer la funcionalidad
necesaria y definida por DRI para el Solicitar /
Entregar.
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
OAI-PMH
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.
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
Buscar 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.
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.
Empaquetació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
31
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.
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
Publicación peticiones remotas de Presentar / Almacenar.
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.
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
Entregar 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
32
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.
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.
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.
Catalogación 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.
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
Contenidos
noticias y los feeds o descargarse los recursos puestos a su
Portales
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.
Componente que implementa los servicios de la herramienta de

modificación introducida en el cambio C14. Permite configurar
Modificador
tareas para la modificación en bloque de múltiples ODEs y se
encarga de ejecutar dichas tareas y generar informe de resultados.
33
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.
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.
por el sistema de reputación que permitirá dar de alta un
comentario y una valoración asociada a un ODE así como
Valoración 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.
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
Indexador y
componente Buscar.
Buscador
• 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.
Componente que engloba la gestión y explotación de las fuentes

taxonómicas, los tesauros, árboles curriculares y los vocabularios
Fuentes controlados. Éstos se importan conforme a un esquema previamente
Taxonómicas 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
34
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
35
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?
36
Manual módulo 3
Instalación
(Componentes de la plataforma)
37
Índice
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
38
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.
39
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.
40
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.
41
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:
42
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 1 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.
43
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
44
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).
FIREWALL
DMZ
Servidor Web
APACHE
:3306
FIREWALL
Interno
Red De Datos Red De Aplicación
Servidor Aplicaciones
JBOSS
Servidor de BBDD
MYSQL
:3306
Red De Almacenamiento
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:
45
# 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
46
# 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
47
# 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
read_buffer = 2M
write_buffer = 2M
[myisamchk]
key_buffer = 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
48
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.
49
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:
50
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.
51
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:
52
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
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
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
53
• 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. 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
54
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
Tamaño de la generación permanente.
-XX:MaxPermSize
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.
55
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
Recomendación
Collector
Se emplea cuando se desea mejorar el rendimiento de la aplicación y
disponemos de múltiples procesadores. Las recolecciones mayores o
Throughput
completas son iguales que en el recolector serie, sin embargo, en un
collector
host con N CPUs, usará N hilos recolectores para las recolecciones
menores o parciales.
Si la aplicación puede permitirse compartir los recursos de
Concurrent procesadores con el recolector mientras se está ejecutando podemos
low pause beneficiarnos de menores pausas durante la recolección. Típicamente
collector las aplicaciones que tienen datos que permanecen en memoria
durante bastante tiempo y con uno o dos procesadores.
El modo incremental se consigue gracias a que el trabajo realizado
Incremental concurrentemente por el recolector se divide en pequeñas porciones
low pause de tiempo programadas entre las recolecciones de la memoria young
collector 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
56
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
57
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.
58
/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
59
# 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
60
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:
61
HTTP
Descripción Valor por
Parámetro
defecto
La longitud máxima de la cola de conexiones
entrantes cuando todos los hilos que atienden
acceptCount peticiones están en uso. Cualquier petición de 100
conexión que se reciba cuando todos los threads
estén en uso será rechazada.
El número de milisegundos que el conector
60.000
connectionTimeout esperará, después de aceptar una conexión, hasta
(60 sg)
que se le solicite la petición de URI.
Este flag permite al contenedor de servlets usar un
disableUploadTimeout tiempo máximo de espera diferente mientras se true
esta ejecutando el servlet.
Define el tamaño máximo de la cabecera HTTP de 4096
maxHttpHeaderSize la petición y de la respuesta (especificado en bytes (4
bytes). KB)
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
maxKeepAliveRequests HTTP/1.0 keep-alive y HTTP/1.1 keep-alive y 100
pipelining.
Si se especifica el valor -1 se permitirán infinitas
peticiones encoladas.
El máximo número de hilos procesadores de
peticiones sin usar que pueden existir hasta que el
maxSpareThreads 50
pool de hilos comienza a parar los hilos
innecesarios.
peticiones creados por el conector. Determina el
maxThreads 200
máximo número de peticiones simultáneas que
pueden ser procesadas.
Número de hilos procesadores de peticiones
minSpareThreads 4
creados cuando el conector arranca.
El puerto TCP sobre el cual el conector creará el
port socket servidor de Java esperando peticiones -
entrantes.
AJP
Valor por
Parámetro Descripción
defecto
El número de milisegundos que el conector esperará,
connectionTimeout después de aceptar una conexión, hasta que se le Infinito
solicite la petición de URI.
maxSpareThreads peticiones sin usar que pueden existir hasta que el 50
pool de hilos comienza a parar los hilos innecesarios.
peticiones creados por el conector. Determina el
maxThreads 200
máximo número de peticiones simultáneas que
pueden ser procesadas.
Número de hilos procesadores de peticiones creados
minSpareThreads 4
cuando el conector arranca.
El puerto TCP sobre el cual el conector creará el
port socket servidor de Java esperando peticiones -
entrantes.
62
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.
63
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.
64
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>
name="jboss.mq.destination:service=Queue,name=B">
</mbean>
name="jboss.mq.destination:service=Queue,name=C">
</mbean>
name="jboss.mq.destination:service=Queue,name=D">
</mbean>
name="jboss.mq.destination:service=Queue,name=auditarQueue">
</mbean>
name="jboss.mq.destination:service=Queue,name=modificador">
</mbean>
name="jboss.mq.destination:service=Queue,name=ex">
</mbean>
…
65
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í:

<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">
66
</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)
67
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.).
68
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
69
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:

<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
70
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
71
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.
72
########## 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
73
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.
###############################
74
####### 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.
75
######## 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.
76
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
77
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
78
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 ################
79
# 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,
80
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=
81
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"
82
class="org.jboss.logging.appender.DailyRollingFileAppender">
<param name="File" value="${jboss.server.log.dir}/service-error.log"/>


-->

-->
</layout>
</appender>
<appender name="agrega" class="org.jboss.logging.appender.DailyRollingFileAppender">

<param name="File" value="${jboss.server.log.dir}/agrega.log"/>


-->

-->
</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">
83
<priority value="ERROR" />
<appender-ref ref="ServiceErrors"/>
</category>
<category name="es.pode">
<appender-ref ref="agrega"/>
</category>
<category name="es.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>
<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:

<!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">
84
<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
85
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">

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:
86
COLA JMS
Publicación
RMI
RemotingGalleryServer
$fileType == "image" $fileType == "video"
else
convert Firefox
¡BOOM! ffmpeg
+
import
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
87
# 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]"
88
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
89
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:
90
Extension2=/opt/jboss/.mozilla/firefox/a6czhy0t.default/
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)
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:
91
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.
92
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/).
93
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
94
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
95
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.
96
• 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
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>
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
97
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?idio
ma=$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/(.+)/(.+)$
98
/visualizadorcontenidos/Noticia/NoticiaCategoria.do?idCategoria%1&%2 [PT,L]
RewriteCond %{QUERY_STRING} ^(.+)&idCategoria(.+)$
/visualizadorcontenidos/Noticia/NoticiaCategoria.do?%1&idCategoria%2 [PT,L]
/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>
99
ServerName cas-<nodo>.agrega.indra.es
JkMount /cas/* <nodo>


</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>


</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
100
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
101
<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:
102
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
103
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

Keep-Alive: 300
HTTP/1.x 302 Movido temporálmente

Date: Tue, 30 Sep 2008 07:56:31 GMT
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=62F1F
E67D9BCC35F09C7EF4DF0521D48
Content-Length: 0
Content-Type: text/html;charset=ISO-8859-1
----------------------------------------------------------
GET
/visualizadorcontenidos/Portada/Portada.do;jsessionid=62F1FE67D9BCC35F09C7EF4DF0521
D48 HTTP/1.1
104
Keep-Alive: 300
Cookie: JSESSIONID=62F1FE67D9BCC35F09C7EF4DF0521D48
HTTP/1.x 200 OK
Date: Tue, 30 Sep 2008 07:56:31 GMT
date=200610162339)/Tomcat-5.5
Content-Language: es-ES
Transfer-Encoding: chunked
----------------------------------------------------------
http://redes.agrega.indra.es/static/img/favicon.ico
GET /static/img/favicon.ico HTTP/1.1

Accept: image/png,image/*;q=0.8,*/*;q=0.5
Keep-Alive: 300
HTTP/1.x 200 OK
Date: Tue, 30 Sep 2008 07:56:31 GMT
Last-Modified: Mon, 11 Aug 2008 11:21:52 GMT
Etag: "f02cb-e36-5cadd400"
Accept-Ranges: bytes
Content-Length: 3638
Content-Type: text/plain
----------------------------------------------------------
http://redes.agrega.indra.es/static/js/plantilla.js
GET /static/js/plantilla.js HTTP/1.1

Accept: */*
Keep-Alive: 300
Referer:
105
HTTP/1.x 200 OK
Date: Tue, 30 Sep 2008 07:56:31 GMT
Last-Modified: Thu, 07 Aug 2008 10:40:44 GMT
Etag: "f0202-33d-5235a300"
Content-Length: 829
Content-Type: application/x-javascript
----------------------------------------------------------
http://redes.agrega.indra.es/static/css/red.css
GET /static/css/red.css HTTP/1.1

Accept: text/css,*/*;q=0.1
Keep-Alive: 300
Referer:
HTTP/1.x 200 OK
Date: Tue, 30 Sep 2008 07:56:31 GMT
Last-Modified: Thu, 07 Aug 2008 10:11:36 GMT
Etag: "f0209-32191-ea054600"
Content-Type: text/css
----------------------------------------------------------
http://redes.agrega.indra.es/static/js/mootools.js
GET /static/js/mootools.js HTTP/1.1

Accept: */*
Keep-Alive: 300
Referer:
HTTP/1.x 200 OK
Date: Tue, 30 Sep 2008 07:56:32 GMT
106
Last-Modified: Thu, 05 Jun 2008 11:56:00 GMT
Etag: "f0201-a8c3-761b400"
----------------------------------------------------------
http://redes.agrega.indra.es/static/js/calendar.rc4.js
GET /static/js/calendar.rc4.js HTTP/1.1

Accept: */*
Keep-Alive: 300
Referer:
HTTP/1.x 200 OK
Date: Tue, 30 Sep 2008 07:56:32 GMT
Last-Modified: Tue, 05 Aug 2008 15:43:46 GMT
Etag: "f01fc-88df-52423080"
----------------------------------------------------------
http://redes.agrega.indra.es/static/img/senal.gif
GET /static/img/senal.gif HTTP/1.1

Keep-Alive: 300
Referer: http://redes.agrega.indra.es/static/css/red.css
HTTP/1.x 200 OK
Date: Tue, 30 Sep 2008 07:56:32 GMT
Last-Modified: Tue, 27 May 2008 08:57:22 GMT
Etag: "f036a-166-7bf7a080"
107
Content-Length: 358
Content-Type: image/gif
----------------------------------------------------------
http://redes.agrega.indra.es/static/img/buscador_widget.gif
GET /static/img/buscador_widget.gif HTTP/1.1

Keep-Alive: 300
HTTP/1.x 200 OK
Date: Tue, 30 Sep 2008 07:56:32 GMT
Last-Modified: Tue, 27 May 2008 08:56:40 GMT
Etag: "f029f-4de-7976c200"
----------------------------------------------------------
http://redes.agrega.indra.es/static/img/cabecera.jpg
GET /static/img/cabecera.jpg HTTP/1.1

Keep-Alive: 300
HTTP/1.x 200 OK
Date: Tue, 30 Sep 2008 07:56:32 GMT
Last-Modified: Thu, 01 Mar 2007 17:15:36 GMT
Etag: "f02a2-146-a3acfe00"
Content-Length: 326
Content-Type: image/jpeg
----------------------------------------------------------
http://redes.agrega.indra.es/static/img/barrita.gif
108
GET /static/img/barrita.gif HTTP/1.1
Keep-Alive: 300
HTTP/1.x 200 OK
Date: Tue, 30 Sep 2008 07:56:32 GMT
Last-Modified: Mon, 30 Oct 2006 15:44:32 GMT
Etag: "f0292-2d-255b3800"
Content-Length: 45
----------------------------------------------------------
http://redes.agrega.indra.es/static/img/06_ingles.gif
GET /static/img/06_ingles.gif HTTP/1.1

Keep-Alive: 300
HTTP/1.x 200 OK
Date: Tue, 30 Sep 2008 07:56:32 GMT
Last-Modified: Mon, 26 May 2008 16:24:20 GMT
Etag: "f0285-5e-9c9a7500"
Content-Length: 94
----------------------------------------------------------
http://redes.agrega.indra.es/static/img/04_valenciano.gif
GET /static/img/04_valenciano.gif HTTP/1.1

109
Keep-Alive: 300
HTTP/1.x 200 OK
Date: Tue, 30 Sep 2008 07:56:32 GMT
Etag: "f0281-4c-9a381b00"
Content-Length: 76
----------------------------------------------------------
http://redes.agrega.indra.es/static/img/05_vasco.gif
GET /static/img/05_vasco.gif HTTP/1.1

Keep-Alive: 300
HTTP/1.x 200 OK
Date: Tue, 30 Sep 2008 07:56:32 GMT
Etag: "f0283-5a-9b4ac380"
Content-Length: 90
----------------------------------------------------------
http://redes.agrega.indra.es/static/img/03_gallego.gif
GET /static/img/03_gallego.gif HTTP/1.1

Keep-Alive: 300
110
HTTP/1.x 200 OK
Date: Tue, 30 Sep 2008 07:56:32 GMT
Etag: "f027f-50-97d5c100"
Content-Length: 80
----------------------------------------------------------
http://redes.agrega.indra.es/static/img/02_catalan.gif
GET /static/img/02_catalan.gif HTTP/1.1

Keep-Alive: 300
HTTP/1.x 200 OK
Date: Tue, 30 Sep 2008 07:56:32 GMT
Etag: "f027d-3d-96490680"
Content-Length: 61
----------------------------------------------------------
http://redes.agrega.indra.es/static/img/01_castellano.gif
GET /static/img/01_castellano.gif HTTP/1.1

Keep-Alive: 300
HTTP/1.x 200 OK
Date: Tue, 30 Sep 2008 07:56:32 GMT
111
Etag: "f027b-3a-923b6d80"
Content-Length: 58
----------------------------------------------------------
http://redes.agrega.indra.es/static/img/logo_redes.gif
GET /static/img/logo_redes.gif HTTP/1.1

Keep-Alive: 300
HTTP/1.x 200 OK
Date: Tue, 30 Sep 2008 07:56:32 GMT
Etag: "f0337-153d-41ae1d80"
----------------------------------------------------------
http://redes.agrega.indra.es/static/img/barra_general.gif
GET /static/img/barra_general.gif HTTP/1.1

Keep-Alive: 300
HTTP/1.x 200 OK
Date: Tue, 30 Sep 2008 07:56:32 GMT
Last-Modified: Fri, 02 Mar 2007 18:19:00 GMT
Etag: "f028f-40b-a440cd00"
112
----------------------------------------------------------
http://redes.agrega.indra.es/static/img/barra_general_der.gif
GET /static/img/barra_general_der.gif HTTP/1.1

Keep-Alive: 300
HTTP/1.x 200 OK
Date: Tue, 30 Sep 2008 07:56:32 GMT
Etag: "f0290-108-b847c100"
Content-Length: 264
----------------------------------------------------------
http://redes.agrega.indra.es/static/img/bullet_off.gif
GET /static/img/bullet_off.gif HTTP/1.1

Keep-Alive: 300
HTTP/1.x 200 OK
Date: Tue, 30 Sep 2008 07:56:32 GMT
Etag: "f029d-43-8d4bac00"
Content-Length: 67
----------------------------------------------------------
http://redes.agrega.indra.es/static/img/dest_01.jpg
GET /static/img/dest_01.jpg HTTP/1.1

113
Keep-Alive: 300
HTTP/1.x 200 OK
Date: Tue, 30 Sep 2008 07:56:32 GMT
Etag: "f02b8-2aa4-98f26900"
----------------------------------------------------------
http://redes.agrega.indra.es/static/img/imagen_00.jpg
GET /static/img/imagen_00.jpg HTTP/1.1

Keep-Alive: 300
HTTP/1.x 200 OK
Date: Tue, 30 Sep 2008 07:56:32 GMT
Last-Modified: Tue, 24 Jun 2008 10:42:56 GMT
Etag: "f030c-140fd-390f4c00"
----------------------------------------------------------
http://redes.agrega.indra.es/static/img/00_logo_gobierno.gif
GET /static/img/00_logo_gobierno.gif HTTP/1.1

Keep-Alive: 300
114
HTTP/1.x 200 OK
Date: Tue, 30 Sep 2008 07:56:32 GMT
Last-Modified: Mon, 02 Jun 2008 08:10:14 GMT
Etag: "f0277-b9e-86740580"
----------------------------------------------------------
http://redes.agrega.indra.es/static/img/00_logo_mepd.gif
GET /static/img/00_logo_mepd.gif HTTP/1.1

Keep-Alive: 300
HTTP/1.x 200 OK
Date: Tue, 30 Sep 2008 07:56:32 GMT
Etag: "f0278-74f-8a078c80"
----------------------------------------------------------
http://redes.agrega.indra.es/static/img/00_logo_red.jpg
GET /static/img/00_logo_red.jpg HTTP/1.1

Keep-Alive: 300
HTTP/1.x 200 OK
Date: Tue, 30 Sep 2008 07:56:32 GMT
115
Last-Modified: Mon, 21 Apr 2008 07:33:06 GMT
Etag: "f027a-5d1-1c51b080"
----------------------------------------------------------
http://redes.agrega.indra.es/static/img/00_logo_avanza.jpg
GET /static/img/00_logo_avanza.jpg HTTP/1.1

Keep-Alive: 300
HTTP/1.x 200 OK
Date: Tue, 30 Sep 2008 07:56:32 GMT
Last-Modified: Mon, 21 Apr 2008 07:33:44 GMT
Etag: "f0274-6bc-1e958600"
----------------------------------------------------------
http://redes.agrega.indra.es/static/img/00_logo_mitc.gif
GET /static/img/00_logo_mitc.gif HTTP/1.1

Keep-Alive: 300
HTTP/1.x 200 OK
Date: Tue, 30 Sep 2008 07:56:32 GMT
Etag: "f0279-650-8b75c280"
116
----------------------------------------------------------
http://redes.agrega.indra.es/static/img/00_logo_europa.gif
GET /static/img/00_logo_europa.gif HTTP/1.1

Keep-Alive: 300
HTTP/1.x 200 OK
Date: Tue, 30 Sep 2008 07:56:32 GMT
Etag: "f0276-906-8e70b300"
----------------------------------------------------------
Si volvemos a solicitar la misma página las peticiones realizadas son:
http://redes.agrega.indra.es/
GET / HTTP/1.1
Keep-Alive: 300
HTTP/1.x 301 Moved Permanently

Date: Tue, 30 Sep 2008 08:12:36 GMT
Location: http://redes.agrega.indra.es/visualizadorcontenidos/
Content-Length: 348
Content-Type: text/html; charset=iso-8859-1
----------------------------------------------------------
http://redes.agrega.indra.es/visualizadorcontenidos/
GET /visualizadorcontenidos/ HTTP/1.1
117
Keep-Alive: 300

Date: Tue, 30 Sep 2008 08:12:36 GMT
date=200610162339)/Tomcat-5.5
Location: http://redes.agrega.indra.es/visualizadorcontenidos/Portada/Portada.do
Content-Length: 0
----------------------------------------------------------
http://redes.agrega.indra.es/visualizadorcontenidos/Portada/Portada.do
GET /visualizadorcontenidos/Portada/Portada.do HTTP/1.1

Keep-Alive: 300
HTTP/1.x 200 OK
Date: Tue, 30 Sep 2008 08:12:36 GMT
date=200610162339)/Tomcat-5.5
Content-Language: es-ES
Transfer-Encoding: chunked
----------------------------------------------------------
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:
118
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=BUSCAD
OR
GET
/buscador/DescargarODECU/SeleccionarTipoFormatoAceptar.do?formato=descargar.format
os.SCORM_2004_VALUE&idioma=es&titulo=Clasifica+aparatos+y+Palabras+locas&identificad
orODE=es_20071214_2_0102201&tipoLayoutBuscador=BUSCADOR HTTP/1.1
Keep-Alive: 300
Referer:
http://redes.agrega.indra.es/buscador/DescargarODECU/DescargarODECU.do?identificador
ODE=es_20071214_2_0102201&idioma=es&tipoLayoutBuscador=BUSCADOR&mostrarVuelta=t
rue

Date: Tue, 30 Sep 2008 08:25:05 GMT
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
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
Keep-Alive: 300
Referer:
http://redes.agrega.indra.es/buscador/DescargarODECU/DescargarODECU.do?identificador
119
ODE=es_20071214_2_0102201&idioma=es&tipoLayoutBuscador=BUSCADOR&mostrarVuelta=t
rue
HTTP/1.x 200 OK
Date: Tue, 30 Sep 2008 08:25:09 GMT
Last-Modified: Tue, 30 Sep 2008 08:25:08 GMT
Etag: "39686b8-8728c-b8b26100"
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
120
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
121
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
122
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?
123
Manual módulo 4
Administración
124
Índice
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
125
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.
126
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.
127
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+).
128
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
129
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.
130
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.
131
2. Plataforma
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.
132
• 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.
133
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.
134
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
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
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.
135
• 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.
136
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:
137
• 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.
138
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.
139
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.
140
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:

<modification-task>
<changes>
...
</changes>
<objects>
141
...
</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:
142
<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:
143
<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>
144
• 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:

<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>
145
</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.
146
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.
147
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
148
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.
149
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
150
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.
151
• 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
152
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,
153
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
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.
154
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
3. Configuración
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
155
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:
156
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.
157
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.
158
Manual módulo 5
Operación
159
Índice
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
160
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.
161
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
162
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

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

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
163
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

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

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]
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
164
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">

<param name="File" value="${jboss.server.log.dir}/server.log"/>

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">
</category>
<category name="ServiceErrorsLogger">
<priority value="ERROR" />
<appender-ref ref="ServiceErrors"/>
</category>
<category name="es.pode">
</category>
<category name="es.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>
<appender-ref ref="CONSOLE"/>
<appender-ref ref="FILE"/>
</root>
165
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.

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
Remote logname (from identd, if supplied). This will return a dash unless
%l
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
Status. For requests that got internally redirected, this is the status of the
%>s
*original* request --- %...>s for the last.
Size of response in bytes, excluding HTTP headers. In CLF format, i.e. a '-'
%b
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:
166
# 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.
167
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
168
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/*
169
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 (*).
170
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
171
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.
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.
172
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).
173
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
174
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.
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>
175
<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
176
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.
177
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?
178
Manual módulo 6
Integración
179
Índice
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
5.1. Alcance
6. DRI
6.1. Alcance
180
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
181
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.
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.
182
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.
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>
183
<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-
184
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:

<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
<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
185
<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-Id: <74D53F983C9A2A6730C4D468C80BF990> {…. contenido binario del
DataHandler…}
Ejemplo 02: llamada al método generarPaquetePif solicitando un ODE que no es

válido.
Llamada:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
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
<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>
</generarPaquetePIFReturn>
186
</generarPaquetePIFResponse>
</soapenv:Body>
</soapenv:Envelope>
Ejemplo 03: llamada al método generarPaquetePifTipoPif solicitando un ODE que

es válido.
Llamada:

<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
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>

información devuelta por el método y un attach conteniendo el ODE serializado.
------=_Part_8_24005374.1214321990043
Content-Id: <AD48DDF0E86D4BD7DC1D8883665A86>

<soapenv:Envelope
<soapenv:Body>
<generarPaquetePIFTipoPIFResponse xmlns="http://servicios.negocio.entregar.pode.es">
<generarPaquetePIFTipoPIFReturn>
<paquetePIF href="cid:86JD2583DDE885DE5E5GF56H7HH331"/>
<resultadoValidacion>
<esValidoManifest>true</esValidoManifest>
<resultadoValidacion></resultadoValidacion>
187
</generarPaquetePIFTipoPIFReturn>
</generarPaquetePIFTipoPIFResponse>
</soapenv:Body>
</soapenv:Envelope>
------=_Part_8_24005374.1214321990043
Content-Id: <86JD2583DDE885DE5E5GF56H7HH331>
{…. contenido binario del DataHandler…}
Proyecta las diapositivas 138 y 139.
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
188
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?v
erb=Identify

<OAI-PMH
xmlns:oai_id="http://www.openarchives.org/OAI/2.0/oai-identifier"
xmlns="http://www.openarchives.org/OAI/2.0/"
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</bas
eURL>
<protocolVersion>2.0</protocolVersion>
<adminEmail>email@indra.es</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>
189
<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.
http://urlRepositorioAgrega?verb=ListMetadataFormats
Como resultado se obtendrá un xml con los tipos de metadatos.
3.2.4. Ejemplo
erb=ListMetadataFormats

<OAI-PMH xmlns="http://www.openarchives.org/OAI/2.0/"
http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd">
<request
verb="ListMetadataFormats">http://redes.agrega.indra.es/oaipmh/OaiPmhRequest/OaiPm
hRequest.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/</metadataNamesp
ace>
</metadataFormat>
</ListMetadataFormats>
</ OAI-PMH>
190
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
Como resultado se obtendrá un xml con los conjuntos.
3.3.4. Ejemplo
erb=ListSets

<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

ListIdentifiers.
• from: Opcional. Fecha a partir de la cual se quiere obtener la lista
191
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.
http://urlRepositorioAgrega?verb=ListIdentifiers&metadataPrefix=oai_
d
Como resultado se obtendrá un xml con la lista de los identificadores.
3.4.4. Ejemplo
erb=ListIdentifiers&metadataPrefix=oai_dc

<request verb="ListIdentifiers"
metadataPrefix="oai_dc">http://redes.agrega.indra.es/oaipmh/OaiPmhRequest/OaiPmhRe
quest.do
</request>
<ListIdentifiers>
<header>
<identifier>oai:agrega.es:es-ic_20080410_1_9075517</identifier>
<datestamp>2008-04-10</datestamp>
</header>
<header>
</header>
<header>
</header>
<header>
</header>
<header>
192
</header>
<header>
</header>
<header>
<identifier>oai:agrega.es:es_20071116_3_0182000</identifier>
</header>
<header>
</header>
<header>
</header>
<header>
</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.
http://urlRepositorioAgrega?verb=GetRecord&metadataPrefix=oai
_dc&identifier=identificadorRegistro
Como resultado se obtendrá un xml con la información del registro.
3.5.4. Ejemplo
erb=GetRecord&metadataPrefix=oai_dc&identifier=oai:agrega.es:es-
ic_20080410_1_9075517
193
<OAI-PMH xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
http://www.openarchives.org/OAI/2.0/oai_dc/
http://www.openarchives.org/OAI/2.0/oai_dc.xsd">
<request verb="GetRecord"
identifier="oai:agrega.es:es-ic_20080410_1_9075517"
quest.do</request>
<GetRecord>
<record>
<header>
</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?i
dioma=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
194
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.
http://urlRepositorioAgrega?verb=ListRecords&metadataPrefix=oai_dc
Devuelve un xml con los registros del repositorio.
3.6.4. Ejemplo
erb=ListRecords&metadataPrefix=oai_dc

<OAI-PMH xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
http://www.openarchives.org/OAI/2.0/oai_dc/
http://www.openarchives.org/OAI/2.0/oai_dc.xsd">
<request verb="ListRecords"
quest.do</request>
<ListRecords>
<record>
<header>
</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:contributor/>
195
<dc:type>self assessment</dc:type>
<dc:format>text/html</dc:format>
dioma=es&identificadorODE=es_20071116_2_0162001</dc:identifier>
<dc:source>es_20071116_3_0162000</dc:source>
<dc:relation>ispartof</dc:relation>
<dc:coverage>Universal</dc:coverage>
alike</dc:rights>
</oai_dc:dc>
</metadata>
</record>
<record>
<header>
</header>
<metadata>
<oai_dc:dc>
<dc:contributor/>
alike</dc:rights>
</oai_dc:dc>
</metadata>
</record>
<record>
<header>
</header>
<metadata>
<oai_dc:dc>
196
<dc:contributor/>
alike</dc:rights>
</oai_dc:dc>
</metadata>
</record>
<record>
<header>
</header>
<metadata>
<oai_dc:dc>
<dc:contributor/>
alike</dc:rights>
</oai_dc:dc>
</metadata>
</record>
<record>
<header>
</header>
<metadata>
<oai_dc:dc>
197
<dc:contributor/>
alike</dc:rights>
</oai_dc:dc>
</metadata>
</record>
<record>
<header>
</header>
<metadata>
<oai_dc:dc>
<dc:contributor/>
alike</dc:rights>
</oai_dc:dc>
</metadata>
</record>
<record>
<header>
</header>
<metadata>
<oai_dc:dc>
198
<dc:contributor/>
alike</dc:rights>
</oai_dc:dc>
</metadata>
</record>
<record>
<header>
</header>
<metadata>
<oai_dc:dc>
<dc:contributor/>
alike</dc:rights>
</oai_dc:dc>
</metadata>
</record>
<record>
<header>
</header>
<metadata>
<oai_dc:dc>
199
<dc:contributor/>
alike</dc:rights>
</oai_dc:dc>
</metadata>
</record>
<record>
<header>
</header>
<metadata>
<oai_dc:dc>
<dc:contributor/>
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>
200
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.

<request>http://redes.agrega.indra.es/oaipmh/OaiPmhRequest/OaiPmhRequest.do</requ
est>
<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.

<request
verb="ListIdentifiers">http://redes.agrega.indra.es/oaipmh/OaiPmhRequest/OaiPmhReque
st.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.

<request verb="ListIdentifiers"
metadataPrefix="oai_d">http://redes.agrega.indra.es/oaipmh/OaiPmhRequest/OaiPmhReq
uest.do</request>
201
<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.

<request verb="GetRecord" identifier="asdfsdf"
quest.do</request>
<error code="idDoesNotExist">El identificador no existe en la plataforma</error>
</OAI-PMH>
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.
202
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.
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:Body>
<createSession xmlns="http://Sesion.servicios.negocio.dri.pode.es">
<userID>admincatalogador</userID>
<password>admincatalogador</password>
</createSession>
203
</soapenv:Body>
</soapenv:Envelope>
Respuesta: se obtiene como respuesta identificador de sesión válido.

<soapenv:Body>
<createSessionResponse
xmlns="http://Sesion.servicios.negocio.dri.pode.es">
<createSessionReturn>ff8080811ad87512011ad8a4084d0002</createSessionReturn>
</createSessionResponse>
</soapenv:Body>
</soapenv:Envelope>
4.2.2. createAnonymousSession
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
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: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.

<soapenv:Body>
<createAnonymousSessionResponse
204
xmlns="http://Sesion.servicios.negocio.dri.pode.es">
<createAnonymousSessionReturn>ff8080811ad87512011ad8a4c2220003</createAno
nymousSessionReturn>
</createAnonymousSessionResponse>
</soapenv:Body>
</soapenv:Envelope>
4.2.3. destroySession
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:Body>
<m:destroySession xmlns:m="http://Sesion.servicios.negocio.dri.pode.es">
<m:sessionID>ff8080811ad87512011ad8a4c2220003</m:sessionID>
</m:destroySession>
</SOAP-ENV:Body>
Respuesta: no hay respuesta a esta llamada.

<soapenv:Body>
<destroySessionResponse
xmlns="http://Sesion.servicios.negocio.dri.pode.es"/>
</soapenv:Body>
</soapenv:Envelope>
205
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
206
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.
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
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
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:xsi="http://www.w3.org/2001/XMLSchema-
instance"><soapenv:Body><getTotalResultsCount
xmlns="urn:www.cenorm.be/isss/ltws/wsdl/SQIv1p0"><targetSessionID>ff8080811ada04730
11ada6c636b0004</targetSessionID><queryStatement><simpleQuery><term>est
rellas</term></simpleQuery></queryStatement></getTotalResultsCount></soa
penv:Body></soapenv:Envelope>
Respuesta: se obtiene como respuesta el número de resultados que ha producido la

consulta.
207
<?xml version="1.0" encoding="utf-8"?><soapenv:Envelope
instance"><soapenv:Body><getTotalResultsCountResponse
xmlns="urn:www.cenorm.be/isss/ltws/wsdl/SQIv1p0"><getTotalResultsCountReturn>1</get
TotalResultsCountReturn></getTotalResultsCountResponse></soapenv:Body></soapenv:Env
elope>
5.2.2. setMaxDuration
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.
de lo ocurrido: identificador de sesión inválido, número de milisegundos inválido o
cualquier otro error no contemplado.
Ejemplo
Ejemplo 01: llamada al método SetMaxDuration enviando un identificador de

sesión y número de milisegundos.
Llamada:
<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>
Respuesta: este método no devuelve ningún dato.
208
<soapenv:Body>
<setMaxDurationResponse
xmlns="http://SQI.servicios.negocio.dri.pode.es"/>
</soapenv:Body>
</soapenv:Envelope>
5.2.3. setResultsFormat
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.
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
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: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>
209
<soapenv:Body>
<setResultsFormatResponse
</soapenv:Body>
</soapenv:Envelope>
5.2.4. setResultSetSize
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.
de lo ocurrido: identificador de sesión inválido, tamaño de conjunto de resultados
inválido o cualquier otro error no contemplado.
Ejemplo
Ejemplo 01: llamada al método SetResultSetSize enviando un identificador de

sesión y un tamaño de conjunto de resultados.
Llamada:
<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>
210
<soapenv:Body>
<setResultsSetSizeResponse
</soapenv:Body>
</soapenv:Envelope>
5.2.5. setQueryLanguage
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.
de lo ocurrido: identificador de sesión inválido, lenguaje de consulta no soportado
u otro error no contemplado.
Ejemplo
Ejemplo 01: llamada al método SetQueryLamguage enviando un identificador de

sesión y un identificador de lenguaje de consulta.
Llamada:
<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>
211
<soapenv:Body>
<setQueryLanguageResponse
</soapenv:Body>
</soapenv:Envelope>
5.2.6. setMaxQueryResults
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.
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
Ejemplo 01: llamada al método SetMaxQueryResults enviando un identificador de

sesión y un identificador de lenguaje de consulta.
Llamada:

instance"><soapenv:Body><setMaxQueryResults
11ada6c636b0004</targetSessionID><maxQueryResults>10000</maxQueryResults></setMax
QueryResults></soapenv:Body></soapenv:Envelope>

instance"><soapenv:Body><setMaxQueryResultsResponse
212
e>
5.2.7. synchronousQuery
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.
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
Ejemplo 01: llamada al método SynchronousQuery enviando un identificador de

sesión un texto de búsqueda y un identificador de resultados.
Llamada:

instance"><soapenv:Body><synchronousQuery
11ada6c636b0004</targetSessionID><queryStatement><simpleQuery><term>est
rellas</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.

instance"><soapenv:Body><synchronousQueryResponse
xmlns="urn:www.cenorm.be/isss/ltws/wsdl/SQIv1p0"><synchronousQueryReturn><?xml
213
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:Env
elope>
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.
214
• 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.
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
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
Ejemplo 01: llamada al método PresentarAlmacenarSesion enviando un ODE.

Llamada:
215
<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-Id: <C0362C12E70D7B0BD27042C2996704B9>
------=_Part_2_4835957.1214824149296--

información devuelta por el método.

instance"><soapenv:Body><presentarAlmacenarSesionResponse
xmlns="http://DRI.servicios.negocio.dri.pode.es"/></soapenv:Body></soapenv:Envelope>
6.2.2. presentarAlmacenar
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
Ejemplo 01: llamada al método PresentarAlmacenar enviando un ODE.

Llamada
216
<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-Id: <C0362C12E70D7B0BD27042C2996704B8>
------=_Part_2_4835957.1214824149297--


instance"><soapenv:Body><presentarAlmacenarResponse
6.2.3. SolicitarEntregarSesion
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
Ejemplo 01: llamada al método SolicitarEntregarSesion enviando un mec.

Llamada:

<soapenv:Body>
<solicitarEntregarSesion xmlns="http://DRI.servicios.negocio.dri.pode.es">
<sesionId>ff8080811ad92757011ad9275bac0001</sesionId>
<mec>es_20070901_3_0261100</mec>
217
</solicitarEntregarSesion>
</soapenv:Body>
</soapenv:Envelope>

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-Id: <DE89AF93EBB40323FBEF9CD025A66BCB>

instance"><soapenv:Body><solicitarEntregarSesionResponse
xmlns="http://DRI.servicios.negocio.dri.pode.es"><solicitarEntregarSesionReturn
href="cid:E5DB451354A6BD7465318D4DA6E41C8D"/></solicitarEntregarSesionResponse></so
apenv:Body></soapenv:Envelope>
------=_Part_1_17172160.1214825271850
Content-Id: <E5DB451354A6BD7465318D4DA6E41C8D>
6.2.4. solicitarEntregar
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
Ejemplo 01: llamada al método SolicitarEntregar enviando un mec.

Llamada:

instance"><soapenv:Body><solicitarEntregar
xmlns="http://DRI.servicios.negocio.dri.pode.es"><usuario>admincatalogador</usuario><cl
ave>admincatalogador</clave><mec>es_20070901_3_0261100</mec></solicitarEntregar><
/soapenv:Body></soapenv:Envelope>
218
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-Id: <A995CD42245926228341AF8C6C8A1475>

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-Id: <66ACF3BB49B51C3848FC5059ADD0228E>
6.2.5. presentarCatalogarSesion
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
Ejemplo 01: llamada al método SolicitarEntregarSesion enviando un ODE.

Llamada:

<soapenv:Body>
<presentarCatalogarSesion xmlns="http://DRI.servicios.negocio.dri.pode.es">
<sesionId>ff8080811ad92757011ad9516db60003</sesionId>
<pif href="cid:6935E10DBEAC67589B877E24BCDEF3E5" />
</presentarCatalogarSesion>
</soapenv:Body>
</soapenv:Envelope>
219
------=_Part_5_14808011.1214826931450
Content-Id: <6935E10DBEAC67589B877E24BCDEF3E5>
------=_Part_5_14808011.1214826931450--


instance"><soapenv:Body><presentarCatalogarSesionResponse
6.2.6. presentarCatalogar
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
Ejemplo 01: llamada al método PresentarCatalogar enviando un ODE.

Llamada:

<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-Id: <423B4845FBE2C2B094071BF68336DCBB>
220
------=_Part_5_14808011.1214826931450--


instance"><soapenv:Body><presentarCatalogarResponse
¿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.
221
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#125621
5
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/#clusterin
g-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/
222
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
223

Manual para Técnicos

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Manual para Técnicos

Încărcat de

Drepturi de autor:

Formate disponibile

Formación para técnicos

Manual del formador

1. ¿Qué es? ..................................................................................... 11

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

1. Capa de datos .............................................................................. 40

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

1. Arranque y parada de los aplicativos ................................................. 162

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

2. Recursos de apoyo que se van a utilizar

– Manual del docente formado por los materiales que se presentan a

Explicación del docente.

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

Actividades a desarrollar durante la explicación del contenido.

− Conocer los procedimientos para la instalación de nodos de la Plataforma.

− Identificar las tecnologías de base que utiliza la Plataforma.

− Reconocer la estructura, componentes, relaciones y configuración de los

• Módulo 1. Resumen de funcionalidades

5. Perfil del grupo

Perfil: administrador de sistemas Unix.

Funciones en Agrega: mantener, actualizar el nodo de Agrega y diagnosticar los

6. Conocimiento del grupo

Es fundamental a la hora de enfrentarse a una asesoría o un curso formativo

En el primer módulo es aconsejable utilizar alguna técnica de grupos para

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

Lunes Martes Miércoles Jueves Viernes

9.00 -11.00 Módulo 2 Módulo 4 Módulo 5 Módulo 6

11.30-13.00 Módulo 3 Módulo 4 Módulo 5 Dudas y

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

El taller consistirá básicamente en tres fases:

• Puesta en común de los conocimientos previos de los alumnos.

Presentación del grupo 10 minutos

Presentación del taller: organización, objetivos a alcanzar,

Explicación del módulo 1 2 horas

Desarrollo de actividades 1 hora

Explicación del módulo 2 4 horas

Desarrollo de actividades 30 minutos

Explicación del módulo 3 4 horas

Desarrollo de actividades 1 hora

Explicación del módulo 4 3 horas

Desarrollo de actividades 1 hora y 30 minutos

Explicación del módulo 5 6 horas

Desarrollo de actividades 1 hora

Explicación del módulo 6 4 horas

Desarrollo de actividades 30 minutos

Dudas y cierre del taller 1 hora

Evaluación: comprobar el grado de adquisición de los objetivos 30 minutos

10. Procedimiento de evaluación

El fin de la evaluación es el de comprobar el grado de adquisición de los objetivos

d. Temporalidad: la evaluación se llevará a cabo a través de las actividades

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

Contenido del módulo 1

Presentación del taller

Comenzaremos la sesión haciendo una presentación del grupo y

− Identificar la plataforma Agrega y a quién va dirigida.

El proyecto Agrega se ha concebido para adaptarse a las necesidades específicas

Por tanto, Agrega es una plataforma dirigida a toda la comunidad educativa. Es

Dicha plataforma se ha diseñado con la idea de promover la especificación de una

El alcance incluye el desarrollo de las herramientas necesarias para la

• Empaquetado SCORM 2004: desarrolla contenidos de aprendizaje basados en

o Agrega contenido en paquetes transportables.

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