Presentacion para Técnicos
-
Upload
proyecto-agrega -
Category
Documents
-
view
1.255 -
download
0
Transcript of Presentacion para Técnicos
1
Formación para técnicos
Presentación general
2
Objetivos del curso
• Generales– Conocer la plataforma Agrega y potenciar su implementación en las
aulas, utilizando entornos de aprendizaje, flexibles y creativos, en los diferentes niveles de enseñanza y en las distintas áreas curriculares.
• Específicos– Comprobar la facilidad de uso y accesibilidad de Agrega e identificar
los estándares soportados: catalogación LOM, accesibilidad AA e integración con otras plataformas SCORM.
– Identificar las características específicas de la plataforma: uniformidad en estándares, posibilidades de uso de los recursos educativos dentro y fuera de la plataforma, definición y características de objetos de aprendizaje, adecuación por las comunidades autónomas, etc.
– Manejar el buscador como localizador de recursos.– Usar el catalogador de contenidos con el fin de asociar correctamente
los objetos con la metainformación necesaria, y conseguir una adecuada caracterización y localización.
– Identificar los pasos necesarios para crear y publicar contenidos.
3
Contenidos del curso
Módulo 1. Resumen de funcionalidades1. ¿Qué es?2. Componentes básicos
Módulo 2. Arquitectura1. Introducción 2. Arquitectura física3. Arquitectura lógica
Módulo 3. Instalación (Componentes de la plataforma)1. Capa de datos2. Capa de aplicación3. Capa de servidor web
Módulo 4. Administración 1. Contenidos2. Plataforma3. Configuración
4
Contenidos del curso
Módulo 5. Operación1. Arranque y parada de los aplicativos2. Ficheros de Log3. Backups4. Modificaciones frente a cambios frecuentes5. Tareas planificadas6. Generación automática de ficheros7. Seguridad8. Actualización MediaWiki
Módulo 6. Integración1. Integración2. WebServices publicados3. OAI-PMH4. Gestor de sesiones5. SQI6. DRI
5
Módulo 1. Introducción: portal Agrega
• ¿Qué es Agrega? Plataforma dirigida a toda la comunidad educativa que permite a sus miembros elaborar y compartir distintos recursos multimedia orientados al aprendizaje y la enseñanza.
• Características:
– Su interfaz sigue unas pautas y normativas de usabilidad, accesibilidad y multi-idioma que garantizan su uso.
– Permite la creación de redes de repositorios digitales que se interaccionen entre sí con el fin de facilitar a los usuarios el acceso a los contenidos educativos almacenados en estos repositorios.
– 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.
6
Introducción
• ¿Qué es un ODE? Agregación de uno o más elementos digitales, que incorporan metadatos, y que representa una unidad didáctica con significación educativa.
• Características:
– Unidades de contenido autónomas.– Granulares y agregables.– Reciclables.– Interoperables.– Identificados y descritos con metadatos.
7
Introducción
• ¿Qué es un metadato? Es información complementaria que ayuda a conocer el contenido y el propósito de un ODE sin necesidad de acceder a éste.
• Agrega gestiona ODEs con los siguientes estándares:
– Empaquetado SCORM 2004.– Metadatos LOM-ES.
8
Estándares
• SCORM: desarrolla contenidos de aprendizaje basados en entornos Web.
• Características de SCORM:
– Agrega contenido en paquetes transportables.– Realiza la ejecución y el seguimiento del contenido.– Organiza la estructura del contenido.– Define la secuenciación adaptativa de las actividades.
• Componentes de SCORM:
– Contenidos (archivos físicos) agrupados en un paquete Zip.– Archivo maestro en formato XML.– Archivos de control (esquemas XSDs).
9
Estándares
• LOM-ES: organiza los datos que especifican y detallan un ODE.
• Categorías de LOM-ES:
– General– Ciclo de Vida– Meta-metadatos– Técnica– Uso educativo– Derechos– Relación– Anotación– Clasificación
10
Menús comunes
• Este apartado es accesible a todo tipo de usuarios: anónimos, registrados y administradores. Se compone de:
– Acerca de Agrega– Accesibilidad– Preguntas frecuentes– Mapa del portal– Contacto– Idiomas– Acceder/Registrarse– Ayuda– Salir
11
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).
12
Portada
• Consta de los siguientes apartados:
– Noticias: novedades relacionadas acerca de la plataforma.
– Informes: consultas realizadas de los ODEs.– Descargas: Agrega off-line.– Agrega en tu Web: permite añadir a tu
Web información relacionada con Agrega.– RSS o feeds: canales que recogen
información acerca de páginas Web sindicadas.
– Nube de Tags: muestra las palabras clave más repetidas en la plataforma.
13
Carpeta personal
• Se accede a través de la pantalla principal y en ella se almacenan y visualizan los ODEs que el usuario tiene en fase de creación.
• Aparte de crear ODEs, a través de esta carpeta el usuario puede consultar aquellos objetos propuestos para su publicación, así como los publicados en la plataforma Agrega.
14
Carpeta personal
• Está compuesta por tres pestañas:
– Personales. Muestra los ODEs creados o rechazados por el usuario. Permite:
• Modificar• Crear• Exportar• Proponer• Eliminar • Importar• Ver historial
– Propuestos. Muestra los ODEs propuestos a crear por el usuario.– Publicados. Muestra los ODEs creados y publicados por el usuario.
15
Buscador
• Permite buscar los objetos digitales educativos (ODEs) publicados en la plataforma. Éstos se pueden previsualizar y/o descargar.
• Se puede acceder al buscador desde distintos puntos del portal, pudiendo realizarse dos tipos de búsqueda:
– Básica: la búsqueda se realiza configurando un campo de texto.
– Avanzada: la búsqueda se realiza configurando un formulario de criterios detallados que permita localizar los ODEs de una forma más exhaustiva.
16
Búsqueda básica
• Se introducen una o más palabras en la caja de texto.• Es posible seleccionar el idioma con el que queremos realizar la búsqueda.
• Se eligen los nodos entre los que se quiere dirigir la búsqueda:
– Todo Agrega: realiza una búsqueda en todos los nodos de la plataforma disponibles en ese momento y en el nodo local.
– Buscar en CNICE: realiza la búsqueda del término introducido en el servidor local del bando de datos del CNICE.
17
Búsqueda básicaPantalla de resultados
18
Búsqueda básica
Haz clic en la imagen para ver el vídeo
19
Búsqueda avanzada
• La búsqueda se realiza configurando un formulario de criterios para localizar los ODEs de forma más exhaustiva
20
Búsqueda avanzada
Haz clic en la imagen para ver el vídeo
21
Búsqueda Taxonómica
• Para realizar una búsqueda taxonómica es necesario estar registrado.
• Una vez que entramos en este apartado, debemos seleccionar:
• El ámbito de búsqueda:
• Todo Agrega• CNICE
• El tipo de búsqueda:
• Árbol curricular• Tesauro ETB
22
Búsqueda Taxonómica
Haz clic en la imagen para ver el vídeo
23
Empaquetador
• Se trata de una herramienta de empaquetación de objetos digitales educativos, de acuerdo a un estándar (SCORM 2004), que permite generar paquetes SCORM a partir de los contenidos y ficheros del usuario.
• Según el perfil del usuario, el empaquetador será:
– Básico– Avanzado
• Ambos perfiles tienen funcionalidades en común como:
– Catalogar– Previsualizar– Validar – Guardar– Etc.
24
Empaquetador básico
• Se trata de la versión sencilla de la herramienta de empaquetación de contenidos de Agrega. No requiere por parte del usuario ningún conocimiento acerca de estándares de enseñanza electrónica. Se compone de dos vistas: Estructura y Archivos, cada una con diferentes funcionalidades.
25
¿Cómo se crea un ODE?
Haz clic en la imagen para ver el vídeo
26
Empaquetador avanzado
• Se trata de 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. Incluye una gestión completa de: Archivos, Recursos, Organizaciones y Sub-manifiestos.
27
Catalogador
• Su función principal es añadir datos de catalogación (metadatos) al objeto digital educativo que se está creando.
• Dependiendo del perfil elegido habrá dos tipos de catalogador:– Básico– Avanzado
• Las opciones de la cabecera Importar, Exportar y Ayuda son comunes para ambos perfiles.
28
Catalogador básico
• Asocia al ODE editado la metainformación necesaria para una adecuada catalogación (mediante el empaquetador básico) y localización del objeto en la plataforma.
• Componentes:– Formulario: consiste en cumplimentar los diferentes campos.– Inserción curricular: sirve para asociar el ODE a un objetivo
curricular.– Validación: confirma que el ODE está listo para su publicación.– Guardar validación.
29
Formulario del catalogador básico
30
Catalogador avanzado
• Asocia al ODE editado la metainformación necesaria para una adecuada catalogación (mediante el empaquetador avanzado) y localización del objeto en la plataforma.
• Componentes:– Formulario.– Modificar.– Validación.– Guardar validación.
31
Formulario del catalogador avanzado
• Se compone de las siguientes categorías. Cada categoría consta de una serie de campos que hay que rellenar para la futura publicación del ODE:
– General: información genérica del ODE.– Ciclo de Vida: describe el estado actual e histórico del ODE.– Metadatos: describe el propio registro de los metadatos.– Técnica: requisitos y características técnicas del ODE.– Uso educativo: describe las características educativas y pedagógicas
del ODE.– Derechos: derechos de propiedad intelectual y condiciones de uso. – Relación: describe las relaciones, en caso de que las haya, con otros
ODEs.– Anotación: comentarios sobre la utilización pedagógica del ODE.– Clasificación: describe la situación del ODE dentro de un sistema de
clasificación concreto.
32
Administración
• Desde este apartado se lleva a cabo la planificación de una serie de tareas con el fin de ejecutarlas o administrarlas posteriormente en la plataforma.
• Este módulo es exclusivo del administrador. Se compone de:
– Contenidos– Plataforma– Configuración
33
Módulo 2. Arquitectura
Durante este módulo describiremos la arquitectura física y lógica de un nodo de la plataforma. Un nodo responde a la arquitectura de 3 capas o niveles:
Capa servidor WebApachePHP (MediaWiki)Squid (caché opcional)
Capa de aplicaciónJBoss Application ServerJDK 1.6Galería de Imágenes
Capa de datosNFSBase de datos (MySQL)LDAP
34
Arquitectura física
35
Componentes principales
1. Apache
2. JBoss Application Server
3. Base de datos: MySQL
4. LDAP
5. Servidor de ficheros: NFS
36
Conexiones establecidas
Host Origen Puerto Origen Host Destino Puerto Destino* (ANY) * (ANY) Apache 80* (ANY) * (ANY) Apache 443
Apache * (ANY) JBoss 8009Apache * (ANY) MySQL 3306
* (ANY) * (ANY) JBoss 8080
JBoss * (ANY) LDAP 389JBoss * (ANY) MySQL 3306
37
Conexiones establecidas
38
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.
39
Sistema de almacenamiento
Se propone utilizar al menos tres sistemas:
1.Directorio LDAP: se almacenará la información utilizada en los módulos de autenticación.
2.Sistema de ficheros en disco: se utilizará para aquella información que se suele almacenar en archivos, por ejemplo: contenidos, metainformación LOM, trazas del sistema de auditoria, logs, etc.
3.Base de datos: la mayor parte de la información manejada por la Plataforma será almacenada en el sistema de ficheros.
40
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.
41
Módulos funcionales
Componente Descripción
DRI
Componente encargado de la orquestación de los diferentes servicios lógicos que componen el nodo de forma que permita ofrecer al exterior una capa de webservices, denominada Interfaz de interoperabilidad con las funcionalidades de Presentar/Almacenar, Buscar/Mostrar y Solicitar/Entregar.
OAI-PMH
Componente encargado de la coreografía de los diferentes servicios lógicos que compondrán el nodo de forma que se permita a buscadores tipo Google, tener información acerca de los contenidos digitales almacenados en el repositorio que expone el nodo cumpliendo el protocolo.
Buscar Componente encargado de ofrecer servicios de búsqueda y transformar las diferentes búsquedas en el lenguaje entendible por el servicio de Buscador / Indexador.
EmpaquetaciónComponente 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.
PublicaciónComponente encargado de ofrecer servicios al Gestor de Flujo de forma que gestiona el flujo de publicación seguido por un contenido digital.
EntregarComponente encargado de ofrecer los servicios para poder consumir los objetos digitales existentes en el repositorio.
42
Módulos funcionales
Componente Descripción
CatalogaciónComponente 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.
Contenidos PortalesComponente 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.
ModificadorComponente que implementa los servicios de la herramienta de modificación introducida en el cambio C14.
ValoraciónComponente que se encargará de la gestión de la valoración que se dé por parte de los usuarios a los contenidos.
Indexador y Buscador Componente que conforma un recubrimiento lógico del interfaz propuesto por la librería de indexación y búsqueda de Apache Lucene.
Fuentes TaxonómicasComponente que engloba la gestión y explotación de las fuentes taxonómicas, los tesauros, árboles curriculares y los vocabularios controlados.
43
Módulos funcionales
44
Módulo 3. Instalación
Capas de datos
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
45
Sistema de ficheros
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.
46
Sistema de ficheros
47
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. Es aconsejable que el sistema de ficheros de la unidad exportada sea ReiserFS o XFS 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:
•/etc/exports•/etc/hosts.allow•/etc/hosts.deny
48
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 del siguiente modo:
• 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.
49
Base de datos
El portal almacenará cierta información de naturaleza relacional en la base de datos, como:
•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.
50
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).
51
Servidor MySQL
Una vez instalado el servidor MySQL procedemos de la siguiente manera:
•Revisamos la configuración del fichero /etc/my.cnf .•Arrancamos el demonio.•Agregamos una contraseña para el usuario root.•Nos conectamos con el usuario root al servidor MySQL.•Creamos la base de datos para Agrega.•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.•Creamos la base de datos para la ayuda (Mediawiki).•Creamos el usuario wiki_user con acceso de escritura, modificación, borrado y consulta de las tablas de la base de datos wikidb.
52
Base de datos: Agrega
Una vez esté creada la base de datos y el usuario agrega_user, durante la instalación del nodo se ejecutaron los siguientes scripts SQL:
•CrearTablas.sqlEl 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.sqlUna 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).
53
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:
1.De nuevo, debemos ejecutar la inserción del dump con el usuario root puesto que wiki_user no tiene permisos de creación / borrado de tablas.
2.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;
54
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. En caso contrario, se deniega el login y se notifica al usuario el error.
55
Autenticación LDAP
56
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 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 del recurso, para ello, se hace uso de diversas herramientas de software libre tales como ffmpeg, convert, firefox…
57
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 JDK1.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.
2.Editamos el /etc/profile añadiendo las dos exportaciones siguientes:export JAVA_HOME=/opt/jdkexport PATH=$PATH:$JAVA_HOME/bin
58
Servidor de Aplicaciones JBossAS
El portal Agrega es un desarrollo J2EE que puede ser desplegado en cualquier contenedor de aplicaciones J2EE compatible.
Se ha seleccionado JBoss como servidor de aplicaciones por:
•Las características técnicas.•La comunidad open source que hay en torno a JBoss.•La estabilidad mostrada en entornos de producción.•Las continuas mejoras y evoluciones que ha experimentado.
59
Comprobaciones previas del sistema
• Apertura de ficheros. Se comprueba que no existe límite de apertura de ficheros con el comando unlimit –a.
• Máximo número de sockets de red. Para comprobar el valor actual empleamos el siguiente comando: sysctl -a |grep -i somaxconn
• Usuario y grupo JBoss. Se recomienda que el proceso de JBossAS sea lanzado por un usuario con permisos adecuados, así se garantiza que el usuario pueda escribir en los diferentes directorios necesarios para el correcto funcionamiento del portal.
60
Scripts de arranque
1. run.confExiste 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.
2. /etc/init.d/jboss y run.shAl 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.
61
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:
1.Configuración de los conectores de JBoss: HTTP y AJP.2.Datasources.3.Colas JMS.4.Alias en directorios.5.Redirección tráfico 8080.
62
Librerías del JBoss
JBoss tiene dos directorios de librerías:
1.$JBOSS_HOME\libEn el directorio lib contiene los JARs necesario para el set up del
arranque del JBoss.
2. $JBOSS_HOME\server\default\delpoy\libTodos los ficheros JAR del directorio se cargarán por JBoss en el
classpath compartido por todos los módulos (WARs).
63
Directorio de informes
El directorio de informes almacena en su interior los siguientes directorios:
1.birt-runtime-2_2_1_1Para la generación de informes online la plataforma hace uso de Birt.
Los binarios del sistema de reportes Birt se almacenan ahí.
2. destinoInformesDirLos informes planificados desde el planificador se almacenarán en esta
carpeta.
3. plantillasInformesLas plantillas a partir de las cuales Birt genera los informes se
encuentran en esta carpeta.
64
Directorio de índices
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.
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
65
Directorio de uploads
El directorio de uploads es el directorio donde se almacenarán los ficheros necesarios para la plataforma y los ficheros que se irán generando a medida que se use la plataforma.
El tamaño de este directorio será elevado y variará en función de:
1.Los ODEs creados en el taller.2.Los ODEs publicados (tamaño y número) en el repositorio.3.Las descargas disponibles desde la plataforma.
66
Ejemplo de la estructura de subdirectorios
descargasgaleriaimg/common (contiene los iconos de las imágenes por defecto)galeriaimg/<sitio> (se generarán las previsualizaciones de los ODEs)html (con contenido inicial)imagenesInformesinformesPortadamodificadornoticiasrepositoriorssschemas (con contenido inicial)schemasImscp (con contenido inicial)schemasScorm12 (con contenido inicial)schemasVdex (con contenido inicial)searchPlugin (con contenido inicial)sitemaps/backupsitemaps/estatico (con contenido inicial)tallerutilidades (con contenido inicial)xmls (con contenido inicial)xslt (con contenido inicial)
67
Ficheros de configuración de 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.propertiesauthbackend.propertiescas.propertiesdependentServer_EN.propertiesdependentServer.propertiesgeneracionContenidos.propertiesi18n_ca.propertiesi18n_en.propertiesi18n_es.propertiesi18n_eu.propertiesi18n_gl.propertiesi18n.propertiesi18n_va.propertiesimportedServices.propertieslog4j.xmlspringldap.xml
68
Despliegue del aplicativo: WARs
Tanto los servicios como los módulos web se deben desplegar en el directorio $JBOSS_HOME/server/default/deploy/agrega/
Para desplegar un módulo, sobreescribiendo 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.
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.
69
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:
70
Scripts ejecutados
Existen dos scripts que pueden ser ejecutados:
1.resizeimg.shSi la aplicación de antemano conoce que el recurso es una imagen,
invocará directamente al script resizeimg.sh.
2. generateimg.shSi se da el caso contrario, se ejecuta el script generateimg.sh.
71
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
72
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.
73
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.
Podemos ver gráficamente las conexiones al Apache en la siguiente figura:
74
Ficheros de configuración
httpd.conf
•Se habilitan las conexiones persistentes.•Se indica el número de clientes soportados por CPU.•Se cargan los módulos mod_deflate, mod_alias.so, mod_rewrite.so y mod_jk.so.
75
Ficheros de configuración
worker.properties
Define las conexiones entre el Apache y el servidor de aplicaciones JBoss.
worker.list=<nodo>worker.<nodo>.host=<ip_jboss>worker.<nodo>.type=ajp13worker.<nodo>.port=8009worker.<nodo>.connect_timeout=10000worker.<nodo>.prepost_timeout=10000worker.<nodo>.socket_timeout=10#This value must equal server.xml's connectionTimeout of 10 minutesworker.<nodo>.connection_pool_timeout=600
76
Ficheros de configuración
vhost
•Se crea un virtual host diferente en cada CCAA.•Se indica el puerto 80 para recibir todas las direcciones IP. Seespecifica el DocumentRoot, el ServerName y el ServerAlias.•Se definen los alias para el contenido estático del portal, los ficheros de logs, las wikis internacionalizadas y para los subdirectorios del directorio “uploads”.•Se definen los directorios de contenidos estáticos, uploads y wikis.•Se definen un conjunto de RewriteRules para facilitar las URLs y su almacenamiento en favoritos en sistemas externos.•Se definen los módulos que se conectan al JBoss.•Se define un virtual host asociado al módulo de autenticación y otro mediante protocolo seguro.
77
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.
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.
78
Proceso de instalación
• Descomprimir binarios en directorio /export/wiki.
• Crear una nueva entrada para la wiki y volcar la información desde wikidb.sql.
• Crear usuario con todos los permisos excepto el de modificación de esquemas.
79
Ficheros de configuración
1. /export/wiki/LocalSettings.php: almacena la configuración de la wiki.
2. vhost especificado en Apache: se debe definir tanto el Alias como el Directorio donde se encuentre instalada la MediaWiki con permisos de ejecución php.
80
Proxy cache. Squid
En algunas ocasiones, puede ser conveniente instalar un Proxy cachéintermedio 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.
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.
81
Proxy cache. Squid
82
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: se especifican los puertos para recibir peticiones http y enviar consultas a la caché, los servidores DNS, donde situar la caché de Squid y sus logs, los controles de acceso a equipo, etc.
83
Módulo 4. Administración
• Desde este apartado se lleva a cabo la planificación de una serie de tareas con el fin de ejecutarlas o administrarlas posteriormente en la plataforma.
• Este módulo se compone de:
– Contenidos– Plataforma– Configuración
84
Contenidos
• Consta de:
– Noticias: permite crear nuevas noticias o modificar las ya existentes.– Descargas: permite crear, modificar o eliminar las descargas. Éstas
pueden estar:• Activadas• Desactivadas
– Preguntas frecuentes: permite crear, modificar o eliminar preguntas frecuentes o FAQ´s.
85
Agrega off line
• Aplicación de escritorio que facilita las funciones básicas de creación, previsualización y validación de contenidos SCORM 2004, implementadas en los nodos de Agrega, sin necesidad de contar con una conexión a Internet.
86
Agrega off line
• Requisitos de la herramienta off-line:
1. Requisitos hardware:– 200 MB de espacio libre en disco duro.– 1 GB de memoria RAM.
2. Requisitos software:– Máquina virtual de Java (JRE) 1.5 o superior.– Navegador Web (recomendados Internet Explorer 5+ y Firefox 2+).
87
Agrega off line
• Proceso 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 cuyonombre no tenga espacios, por ejemplo:
• C:\Aplicaciones\Agrega -> Correcto• C:\Archivos de Programa\Agr -> Error
88
Proceso de instalación
89
Herramientas Agrega off line
• Para utilizar las herramientas Agrega en tu PC, ve al menú Inicio -> Programas -> Agrega, y ejecuta Iniciar Servidor. Este enlace iniciará la aplicación que contiene las herramientas. El proceso puede ser lento.
• 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 start-up in 17576 ms
90
Herramientas Agrega off line
• 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:
91
Herramientas Agrega off line
• Las opciones disponibles son:
– Crear ODE– Abrir ODE– Visualizar ODE– Validar ODE– Herramienta de modificación– Configurar datos de usuario:
• Datos personales• Tipo de empaquetador/catalogador (básico o avanzado)• Idioma
92
Crear un ODE en off line
Haz clic en la imagen para ver el vídeo
93
Validar y publicar un ODE en off line avanzado
Haz clic en la imagen para ver el vídeo
94
Plataforma
• Este módulo se compone de los siguientes elementos:
– Nodo– Usuarios– Logs– Informes– Planificador– Modificador– Monitorizador– Grupos de usuarios– Taxonomías y Tesauros
95
Nodos
• Se encarga de administrar los nodos que cada comunidad tiene para conectarse a la aplicación.
• Para crear un nodo deben rellenarse los siguientes campos:
– Nodo: nombre explicativo para reconocer el nodo.– Url Nodo: url donde se encuentra el nodo.– Url Web Service: url donde se encuentran los servicios del nodo.– Puerto: puerto por el que se comunica el nodo.– Comunidad Autónoma: nombre de la Comunidad Autónoma a la que
corresponde el nodo.
• Además, los nodos pueden modificarse o eliminarse.
96
Usuarios
• Permite la gestión y el mantenimiento de los usuarios en la plataforma. Esta aplicación tiene las siguientes funcionalidades:
– Listar usuarios.– Crear usuarios.– Modificar usuarios.– Describir usuarios.– Eliminar usuarios.– Listar usuarios inactivos.
97
Informes
• Muestra una lista con los informes creados desde el planificador. Desde esta pantalla se puede:
– Crear informes. Éstos se dividen en:• Informe de Fechas.• Informe de rango.• Informe de usuario.
– Eliminar informes.
98
Informes
Haz clic en la imagen para ver el vídeo
99
Planificador
• 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.
• Se compone de tres pantallas:
– Pendientes– Ejecutándose– Ejecutadas
100
Pendientes
• Muestra un listado con todas las tareas pendientes de ser ejecutadas. Desde esta pantalla se puede:
– Crear tarea. Tipos:• Carga de ODEs• Reindexado• Eliminar ODEs• Informe de fechas• Informe de rango• Informe de usuario
– Eliminar tarea.– Ejecutar tarea.
101
Modificador
• Permite configurar tareas para la modificación en bloque de ODEs múltiples.
• Los cambios que la herramienta permite realizar en la catalogación de los ODEs serán de los siguientes tipos:
– Añadir Término LOM-ES– Eliminar Término LOM-ES– Comprobar Término LOM-ES– Modificar término LOM-ES– Validación
• Además, la herramienta proporciona un código HTML para la configuración de tareas.
102
Taxonomías y Tesauros
• Esta opción permite administrar las diferentes estructuras de la plataforma: árboles curriculares, taxonomías y tesauros.
• Para añadir a la aplicación cualquiera de estas estructuras, deben cumplirse los siguientes requisitos:
– Ser un archivo un XML con formato VDEX.– Debe validar contra el VDEX de la estructura.– 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.
103
Configuración
• Se compone de los siguientes apartados:
– Publicador: se encarga de administrar los ODEs publicados y los despublicados. Los publicados se pueden rechazar o publicar; mientras que los despublicados se pueden eliminar o volver a publicar. Para publicar un ODE es necesario ser un usuario con rol de publicador.
104
Configuración
– Catalogador: se encarga de administrar los ODES pendientes de catalogación. Los ODEs se pueden proponer para su publicación o modificación. Para publicar un ODE, hay que tener el rol de publicador; y para modificarlo (Modificar), el de empaquetador.
105
Proponer y publicar
Haz clic en la imagen para ver el vídeo
106
Módulo 5. Operación
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.
•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.
107
Arranque y parada de los aplicativos
JBoss. Arranque y parada
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
108
Arranque y parada de los aplicativos
JBoss. 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:
1.Paramos el servidor de aplicaciones JBoss.2.Borramos el contenido del directorio:
$JBOSS_HOME/server/default/tmp/deploy/3. Borramos el contenido del directorio:
$JBOSS_HOME/server/default/work/jboss.web/localhost/4. Desplegamos los nuevos WARS, properties, etc.5. Arrancamos el servidor de aplicaciones JBoss.
109
Arranque y parada de los aplicativos
Servidor Web Apache
Arranque:/etc/init.d/httpd start
Parada:/etc/init.d/httpd stop
Recarga en caliente de la configuración sin pérdida de servicio:/etc/init.d/httpd graceful
Para comprobar si se encuentra Apache arrancado podemos ejecutar el comando:ps auxww | grep –i httpd
Obteniéndose una salida similar a la siguiente:apache 28745 0.0 0.9 28780 9368 ? S 09:54 0:00 /usr/sbin/httpdapache 849 0.0 1.7 36688 18288 ? S 10:54 0:00 /usr/sbin/httpd
110
Arranque y parada de los aplicativos
MySQL
Arranque:/etc/init.d/mysql start
Parada:/etc/init.d/mysql stop
Para comprobar si se encuentra el servicio de base de datos MySQL arrancado podemos ejecutar el comando:ps auxww | grep –i mysqld
Obteniéndose una salida similar a la siguiente:mysql 2754 2.5 11.9 2412144 311028 ? Sl Sep29 24:31 /usr/sbin/mysqld --basedir=/ --datadir=/var/lib/mysql --user=mysql --pid-file=/var/lib/mysql/database.agrega.indra.es.pid --skip-external-locking --port=3306 --socket=/var/lib/mysql/mysql.sock
111
Arranque y parada de los aplicativos
LDAP
Arranque:/etc/init.d/ldap start
Parada:/etc/init.d/ldap stop
Para comprobar si se encuentra el servicio de directorio LDAP arrancado podemos ejecutar el comando:ps auxww | grep –i slapd
Obteniéndose una salida similar a la siguiente:ldap 29512 0.0 0.3 27660 3736 ? Ssl Sep28 0:00 /usr/sbin/slapd -u ldap -h ldap:/// -s 9
112
Arranque y parada de los aplicativos
Servidor NFS
Arranque:/etc/init.d/nfs start
Parada:/etc/init.d/nfs stop
Para comprobar si se encuentra el servicio de exportación NFS arrancado podemos ejecutar el comando:ps auxww | grep –i nfsd
Obteniéndose una salida similar a la siguiente:root 2925 0.1 0.0 0 0 ? S Mar04 350:01 [nfsd]root 2926 0.1 0.0 0 0 ? S Mar04 349:45 [nfsd]
113
Ficheros de Log
JBoss
Por defecto los logs se almacenan en $JBOSS_HOME/server/default/log. En el fichero $JBOSS_HOME/server/default/conf/log4j.xml definimos los appenders con la ubicación y la política de rotado.
<appender name="FILE" class="org.jboss.logging.appender.DailyRollingFileAppender">
<errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/><param name="File" value="${jboss.server.log.dir}/server.log"/><param name="Append" value="true"/>
<!-- Rollover at midnight each day --><param name="DatePattern" value="'.'yyyy-MM-dd"/>
114
Ficheros de Log
Apache
Una vez confirmado que se encuentra presente el módulo en la configuración de Apache (httpd.conf) LoadModule log_config_module modules/mod_log_config.so, en cada fichero de configuración del virtual host especificamos tanto el formato de log a emplear como el fichero donde almacenarlo.
LogFormat "%h %l %u %t \"%r\" %>s %b" extendedlogCustomLog logs/<sitio>_access.log extendedlogErrorLog logs/<sitio>_error.log
115
Ficheros de Log
MySQL
Si en el fichero de configuración my.cnf se ha habilitado la opción “log-bin”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
116
Ficheros de Log
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
117
Backups
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 se aconseja el siguiente procedimiento:
mysqldump --opt -c -e -Q –h $HOST --hex-blob -u usuario -ppassword $DBNAME > $BACKUP_DIR/$DATABASE-dump-$FECHA.sql
118
Backups
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
119
Backups
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 se encuentran en formato ZIP, por lo que intentar aplicar cualquier algoritmo de compresión apenas reduciráel espacio.
120
Backups
Í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.
121
Backups
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.
122
Backups
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.
123
Backups
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.
124
Backups
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:000 22 1 * * /home/backup/script_bd.sh# Más ejemplos0 2 * * 1-6 sh /raid/Backups_Data/pruebas/MyBackup.sh Diario0 2 * * 0 sh /raid/Backups_Data/pruebas/MyBackup.sh Semanal0 2 1 * * sh /raid/Backups_Data/pruebas/MyBackup.sh Mensual
125
Modificaciones frente a cambios frecuentes
Modificación de la base de datos del portal Agrega
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
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.
126
Modificaciones frente a cambios frecuentes
Modificación de la base de datos de MediaWiki
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";
127
Modificaciones frente a cambios frecuentes
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
128
Modificaciones frente a cambios frecuentes
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
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.
129
Tareas planificadas
La plataforma dispone de un planificador de tareas basado en Quartz. El planificador permite programar tareas de mantenimiento como:
1.Carga de ODEs: Permite cargar al repositorio nuevos objetos educativos.2.Reindexado: Borra los índices del nodo para rehacerlos.3.Eliminar ODEs: Lanza un borrado de objetos del repositorio.4.Generación de informes: Genera de forma programada un informe del tipo especificado.
130
Tareas planificadas
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.
131
Tareas planificadas
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.
1.Carga de ODEs.2.Reindexado.3.Eliminación de ODEs.4.Informes.
132
Generación automática de ficheros
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.
133
Generación automática de ficheros
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.
134
Generación automática de ficheros
Captura de ODE aleatorio
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.
135
Generación automática de ficheros
Generación de 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 resultante con el catálogo se almacena en el directorio referenciado por el atributo destinoInformesDir del fichero agrega.properties.
136
Generación automática de ficheros
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.
137
Módulo 6. Integración
Para añadir valor a los objetos almacenados en la plataforma Agrega, 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.
•WebServices publicados•OAI-PMH•Gestor de sesiones•SQI•DRI
138
Webservices publicados
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.
139
Webservices publicados
Entregar
La plataforma AGREGA cumple con la especificación SCORM 2004, gracias a la que se hace posible la creación de contenidos que puedan importarse dentro de sistemas de gestión de aprendizaje diferentes.
Los principales requerimientos que el modelo SCORM trata de satisfacer son:
•Accesibilidad.•Adaptabilidad.•Durabilidad.•Interoperabilidad.•Reusabilidad.
De acuerdo con estos requerimientos, el módulo Entregar permite el intercambio de ODEs del repositorio de la plataforma y la reutilización por plataformas que soportan modelos anteriores, como SCORM 1.2 o IMS-CP.
140
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.
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.
141
OAI-PMH
Identify
Argumentos:verb: Obligatorio. Se pasará la operación que se quiere realizar en este caso Identify.
Formato de 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
Formato de salida:Como respuesta el Agrega devolverá un XML codificado en UTF-8 con toda la información del repositorio.
142
OAI-PMH
ListMetadataFormats
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.
Formato de llamada:
http://urlRepositorioAgrega?verb=ListMetadataFormats
Formato de salida:
Como resultado se obtendrá un xml con los tipos de metadatos.
143
OAI-PMH
ListSets
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.
Formato de llamada:
http://urlRepositorioAgrega?verb=ListSets
Formato de salida:
Como resultado se obtendrá un xml con los conjuntos.
144
OAI-PMH
ListIdentifiers
Argumentos:
verb: Obligatorio. Operación que se quiere realizar en este caso ListIdentifiers.from: Opcional. Fecha a partir de la cual se quiere obtener la lista 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.
Formato de llamada:http://urlRepositorioAgrega?verb=ListIdentifiers&metadataPrefix=oai_d
Formato de salida:
Como resultado se obtendrá un xml con la lista de los identificadores.
145
OAI-PMH
GetRecord
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.
Formato de llamada:
http://urlRepositorioAgrega?verb=GetRecord&metadataPrefix=oai_dc&identifier=identificadorRegistro
Formato de salida:
Como resultado se obtendrá un xml con la información del registro.
146
OAI-PMH
ListRecords
Argumentos:
verb: Obligatorio. Operación que se quiere realizar en este caso ListRecords.from: Opcional. Fecha a partir de la cual se quiere obtener la lista selectiva de registros.until: Opcional. Fecha hasta la cual se quiere obtener la lista selectiva de registros.metadataPrefix: Obligatorio. Tipo de metadato que deben soportar los registros. En el caso de la plataforma agrega será oai_dc (Dublín Core).Set: Opcional. Identificador del conjunto.resumptionToken: Opcional. Token necesario para el control de flujo.
Formato de llamada:
http://urlRepositorioAgrega?verb=ListRecords&metadataPrefix=oai_dc
Formato de salida:
Devuelve un xml con los registros del repositorio.
147
Mensajes de error
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.
•BadVerb.•BadArgument.•CannotDisseminateFormat.•idDoesNotExist.
OAI-PMH
148
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.
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.
149
Gestor de sesiones
Integración a través de WebServices
Se describen 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.
•createSession.•createAnonymousSession.•destroySession.
150
Gestor de sesiones
createSession
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.
151
Gestor de sesiones
createAnonymousSession
El método tiene el siguiente aspecto:
CreateAnonymousSession () throws Exception
Este método no requiere parámetros y devuelve un identificador de sesión válido con el que poder interaccionar con la plataforma.
152
Gestor de sesiones
destroySession
El método tiene el siguiente aspecto:
DestroySession (String sessionID) throws Exception
Este método toma como parámetro el identificador de la sesión que se quiere eliminar. El resultado de esta operación es la eliminación del sistema de gestión de sesiones de la sesión a la que corresponde el identificador.
153
SQI
Se trata de una especificación que define una capa para facilitar las búsquedas. Especifica un estándar para resolver la problemática de las búsquedas de contenidos digitales en entornos heterogéneos.
Define un API con las siguientes funcionalidades:
• set query language.• set results format.• set max query results.• set max duration.• set results set size.• sychronous query.• get total results count.• asynchronous query.• set source location.• query results listener.
154
SQI
Integración a través de WebServices
Se describen 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.
•getTotalResultsCount•setMaxDuration•setResultsFormat•setResultSetSize•setQueryLanguage•setMaxQueryResults•synchronousQuery
155
SQI
getTotalResultsCount
El método tiene el siguiente aspecto:
GetTotalResultsCount (String targetSessionID, String queryStatement) throws Exception
Este método requiere como parámetros un identificador de sesión y un texto con una consulta.
156
SQI
setMaxDuration
El método tiene el siguiente aspecto:
SetMaxDuration (String targetSessionID, Integer maxDuration) throws Exception
Este método requiere como parámetros un identificador de sesión y un número de entero positivo. El identificador de sesión debe pertenecer a una sesión válida y la cifra se interpreta como milisegundos.
157
SQI
setResultsFormat
El método tiene el siguiente aspecto:
SetResultsFormat (String targetSessionID, String resultsFormat) throws Exception
Este método requiere como parámetros un identificador de sesión y el identificador de un lenguaje de respuesta de resultados de búsqueda. El identificador de sesión debe pertenecer a una sesión válida y el lenguaje, a un lenguaje admitido por la plataforma.
158
SQI
setResultSetSize
El método tiene el siguiente aspecto:
SetResultSetSize (String targetSessionID, Integer resultSetSize) throws Exception
Este método requiere como parámetros un identificador de sesión y una cifra con el tamaño del conjunto de elementos devueltos. El identificador de sesión debe pertenecer a una sesión válida y el tamaño del conjunto de resultados ser válido.
159
SQI
setQueryLanguage
El método tiene el siguiente aspecto:
SetQueryLamguage (String targetSessionID, String queryLanguajeID) throws Exception
Este método requiere como parámetros un identificador de sesión y un identificador de lenguaje de consulta. El identificador de sesión debe pertenecer a una sesión válida y el identificador de lenguaje deberá estar entre los identificadores de lenguajes de consulta aceptados por Agrega (VSQI, LQS).
160
SQI
setMaxQueryResults
El método tiene el siguiente aspecto:
SetMaxQueryResults (String targetSessionID, Integer maxQueryResults) throws Exception
Este método requiere como parámetros un identificador de sesión y un entero con el máximo número de resultados que una búsqueda puede producir. El identificador de sesión debe pertenecer a una sesión válida y el entero deberá ser una cifra válida de resultados de una búsqueda.
161
SQI
synchronousQuery
El método tiene el siguiente aspecto:
SynchronousQuery (String targetSessionID, String queryStatement, Integer startResult) throws Exception
Este método requiere como parámetros un identificador de sesión, una sentencia con el texto de la consulta y un valor entero que indica el índice del primer resultado sobre el total posible a partir del cual se quieren elementos devueltos. El identificador de sesión debe pertenecer a una sesión válida, la sentencia debe estar escrita en un lenguaje admitido por la plataforma Agrega y el valor del índice sobre el total de resultados.
162
DRI
Se trata de una especificación 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.•Exposición.•Almacenamiento.•Entrega.
163
DRI
Integración a través de WebServices
A continuación, se describen en detalle todos los métodos implementados en el API de DRI así como la descripción de los parámetros necesarios para su correcta invocación, los tipos de información devuelta y los errores posibles.
•presentarAlmacenarSesion•presentarAlmacenar•solicitarEntregarSesion•solicitarEntregar•presentarCatalogarSesion•presentarCatalogar
164
DRI
presentarAlmacenarSesion
El método tiene el siguiente aspecto:
PresentarAlmacenarSesion (String sesionId, DataHandler pif) throws Exception
Este método necesita como parámetro un identificador de sesión válido y el fichero que contiene el ODE que se pretende almacenar en formato Pif.
El resultado de la operación es la publicación dentro de la plataforma del ODE suministrado.
165
DRI
presentarAlmacenar
El método tiene el siguiente aspecto:
PresentarAlmacenar (String usuario, String clave, DataHandler pif) throws Exception
Este método necesita como parámetro un usuario válido, su clave dentro del sistema y el fichero que contiene el ODE que se pretende almacenar en formato Pif.
El resultado de la operación es la publicación dentro de la plataforma del ODE suministrado.
166
DRI
solicitarEntregarSesion
El método tiene el siguiente aspecto:
SolicitarEntregarSesion (String sesionId, String mec) throws Exception
Este método necesita un identificador de sesión válida y un identificador de objeto digital que resida publicado en el repositorio. Se devuelve un ODE en formato Pif.
167
DRI
solicitarEntregar
El método tiene el siguiente aspecto:
SolicitarEntregar (String usuario, String clave, String mec) throws Exception
Este método necesita un identificador de usuario válido en la plataforma, su clave dentro del sistema y un identificador de objeto digital que resida publicado en el repositorio. Se devuelve un ODE en formato Pif.
168
DRI
presentarCatalogarSesion
El método tiene el siguiente aspecto:
PresentarCatalogarSesion (String sesionId, DataHandler pif) throws Exception
Este método necesita un identificador de sesión válida y un fichero con un ODE válido en formato pif. El resultado de esta operación es la introducción del recurso digital dentro de la plataforma en estado pendiente de catalogación.
169
DRI
presentarCatalogar
El método tiene el siguiente aspecto:
PresentarCatalogar (String usuario, String clave, DataHandler pif) throws Exception
Este método necesita un identificador de usuario válido en la plataforma, su clave dentro del sistema y un fichero con un ODE válido en formato pif. El resultado de esta operación es la introducción del recurso digital dentro de la plataforma en estado pendiente de catalogación.