Formación para técnicos

Presentación general

1

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

Contenidos del curso
Módulo 1. Resumen de funcionalidades 1. ¿Qué es? 2. Componentes básicos Módulo 2. Arquitectura 1. Introducción 2. Arquitectura física 3. Arquitectura lógica Módulo 3. Instalación (Componentes de la plataforma) 1. Capa de datos 2. Capa de aplicación 3. Capa de servidor web Módulo 4. Administración 1. Contenidos 2. Plataforma 3. Configuración
3

Contenidos del curso
Módulo 5. Operación 1. Arranque y parada de los aplicativos 2. Ficheros de Log 3. Backups 4. Modificaciones frente a cambios frecuentes 5. Tareas planificadas 6. Generación automática de ficheros 7. Seguridad 8. Actualización MediaWiki Módulo 6. Integración 1. Integración 2. WebServices publicados 3. OAI-PMH 4. Gestor de sesiones 5. SQI 6. DRI
4

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.

5

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.

6

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.

7

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

8

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

9

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

10

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

11

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.

12

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

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.

14

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.

15

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.

16

Búsqueda básica Pantalla de resultados

17

Búsqueda básica

Haz clic en la imagen para ver el vídeo

18

Búsqueda avanzada

• La búsqueda se realiza configurando un formulario de criterios para localizar los ODEs de forma más exhaustiva

19

Búsqueda avanzada

Haz clic en la imagen para ver el vídeo

20

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

21

Búsqueda Taxonómica

Haz clic en la imagen para ver el vídeo

22

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.

23

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.

24

¿Cómo se crea un ODE?

Haz clic en la imagen para ver el vídeo

25

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.

26

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.

27

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.

28

Formulario del catalogador básico

29

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.

30

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.

31

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

32

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: Apache PHP (MediaWiki) Squid (caché opcional) JBoss Application Server JDK 1.6 Galería de Imágenes NFS Base de datos (MySQL) LDAP

Capa servidor Web Capa de aplicación Capa de datos

33

Arquitectura física

34

Componentes principales

1. Apache 2. JBoss Application Server 3. Base de datos: MySQL 4. LDAP 5. Servidor de ficheros: NFS

35

Conexiones establecidas

Host Origen * (ANY) * (ANY) Apache Apache * (ANY) JBoss JBoss

Puerto Origen * (ANY) * (ANY) * (ANY) * (ANY) * (ANY) * (ANY) * (ANY)

Host Destino Apache Apache JBoss MySQL JBoss LDAP MySQL

Puerto Destino 80 443 8009 3306 8080 389 3306

36

Conexiones establecidas

37

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.

38

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.

39

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.

40

Módulos funcionales
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. 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. Componente encargado de ofrecer servicios de búsqueda y transformar las diferentes búsquedas en el lenguaje entendible por el servicio de Buscador / Indexador. 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. Componente encargado de ofrecer servicios al Gestor de Flujo de forma que gestiona el flujo de publicación seguido por un contenido digital. Componente encargado de ofrecer los servicios para poder consumir los objetos digitales existentes en el repositorio.

DRI

OAI-PMH

Buscar

Empaquetación

Publicación

Entregar

41

Módulos funcionales
Componente Catalogación Descripción Componente encargado de ofrecer los servicios para poder catalogar, según el estándar LOMES, los distintos contenidos generados y / o almacenados en el repositorio. 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. Componente que implementa los servicios de la herramienta de modificación introducida en el cambio C14. Componente que se encargará de la gestión de la valoración que se dé por parte de los usuarios a los contenidos. Componente que conforma un recubrimiento lógico del interfaz propuesto por la librería de indexación y búsqueda de Apache Lucene. Componente que engloba la gestión y explotación de las fuentes taxonómicas, los tesauros, árboles curriculares y los vocabularios controlados.

Contenidos Portales

Modificador

Valoración

Indexador y Buscador

Fuentes Taxonómicas

42

Módulos funcionales

43

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

44

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.

45

Sistema de ficheros

46

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

47

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.

• •

48

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.

49

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

50

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.

51

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

52

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;

53

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.

54

Autenticación LDAP

55

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…

56

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. 2.Editamos el /etc/profile añadiendo las dos exportaciones siguientes:
export JAVA_HOME=/opt/jdk export PATH=$PATH:$JAVA_HOME/bin

57

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.

58

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.

59

Scripts de arranque

1. run.conf 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. 2. /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.

60

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.

61

Librerías del JBoss

JBoss tiene dos directorios de librerías: 1.$JBOSS_HOME\lib En el directorio lib contiene los JARs necesario para el set up del arranque del JBoss. 2. $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).

62

Directorio de informes

El directorio de informes 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.

63

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 Catalán Inglés Español Euskera Gallego Subdirectorio índices ca_CA_simple.id en_EN_simple.id es_ES_simple.id eu_EU_simple.id gl_GL_simple.id

Valenciano

va_VA_simple.id

64

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.

65

Ejemplo de la estructura de subdirectorios
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)

66

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.properties authbackend.properties cas.properties dependentServer_EN.properties dependentServer.properties 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
67

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.

68

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:

69

Scripts ejecutados Existen dos scripts que pueden ser ejecutados: 1.resizeimg.sh Si la aplicación de antemano conoce que el recurso es una imagen, invocará directamente al script resizeimg.sh. 2. generateimg.sh Si se da el caso contrario, se ejecuta el script generateimg.sh.

70

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

71

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.

72

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:

73

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.

74

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

75

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. Se especifica 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.

76

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.

77

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.

78

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.

79

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.

80

Proxy cache. Squid

81

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.

82

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

83

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.

84

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.

85

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

86

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 cuyo nombre no tenga espacios, por ejemplo: • C:\Aplicaciones\Agrega • C:\Archivos de Programa\Agr -> -> Correcto Error

87

Proceso de instalación

88

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

89

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:

90

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

91

Crear un ODE en off line

Haz clic en la imagen para ver el vídeo

92

Validar y publicar un ODE en off line avanzado

Haz clic en la imagen para ver el vídeo

93

Plataforma • Este módulo se compone de los siguientes elementos: – – – – – – – – – Nodo Usuarios Logs Informes Planificador Modificador Monitorizador Grupos de usuarios Taxonomías y Tesauros

94

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.

95

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.

96

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.

97

Informes

Haz clic en la imagen para ver el vídeo

98

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

99

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.

100

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

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.

102

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.

103

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.

104

Proponer y publicar

Haz clic en la imagen para ver el vídeo

105

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.

106

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

107

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.

108

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 /usr/sbin/httpd apache 849 0.0 /usr/sbin/httpd 0.9 28780 9368 ? S S 09:54 10:54 0:00 0:00
109

1.7 36688 18288 ?

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 --skipexternal-locking --port=3306 --socket=/var/lib/mysql/mysql.sock

110

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 ? /usr/sbin/slapd -u ldap -h ldap:/// -s 9 Ssl Sep28 0:00

111

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 [nfsd] root [nfsd] 2925 2926 0.1 0.1 0.0 0.0 0 0 0 ? 0 ? S S Mar04 350:01 Mar04 349:45

112

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

113

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" extendedlog CustomLog logs/<sitio>_access.log extendedlog ErrorLog logs/<sitio>_error.log

114

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

115

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

116

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

117

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

118

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.

119

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.

120

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.

121

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.

122

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.

123

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

124

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.

125

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 $wgDBname $wgDBuser $wgDBpassword = "localhost"; = "db"; = "user"; = "pass";

126

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

127

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.

128

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.

129

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.

130

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.

131

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.

132

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.

133

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.

134

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.

135

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.

136

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

137

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.

138

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

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.

140

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.

141

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

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

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

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

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

OAI-PMH 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.

147

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.

148

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.

149

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.

150

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.

151

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.

152

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

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

154

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.

155

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.

156

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.

157

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.

158

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

159

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.

160

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.

161

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.

162

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

163

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.

164

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.

165

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.

166

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.

167

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.

168

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.

169

Sign up to vote on this title
UsefulNot useful