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

http://www.proyectoagrega.es/ver_video.php?id=17&secc=tut

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



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



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?



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


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


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


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


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


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


• 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


• 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



93

Validar y publicar un ODE en off line avanzado



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



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



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


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


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


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


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


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

<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


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


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


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


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


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

http://urlrepositorioagrega/?verb=Identify

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.

http://urlrepositorioagrega/?verb=ListMetadataFormats

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.

http://urlrepositorioagrega/?verb=ListSets

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.

http://urlrepositorioagrega/?verb=ListIdentifiers&metadataPrefix=oai_d

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.

http://urlrepositorioagrega/?verb=GetRecord&metadataPrefix=oai_dc&identifier=identificadorRegistro

http://urlrepositorioagrega/?verb=GetRecord&metadataPrefix=oai_dc&identifier=identificadorRegistro

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.

http://urlrepositorioagrega/?verb=ListRecords&metadataPrefix=oai_dc

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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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.

Presentacion para Técnicos

Documents

Transcript of Presentacion para Técnicos