SISTEMA PROPUESTO

Como se comentó en la introducción cuando los usuarios necesitan realizar una acción formativa recurren a los repositorios para encontrar los objetos de aprendizaje que mejor se adapten a dicha formación y con estos confeccionar el contenido que formará parte del material formativo. Como sabemos los objetos de aprendizaje pueden variar con el tiempo, por ejemplo actualizando su contenido, o podemos encontrarnos con nuevos objetos de la misma materia de conocimiento en el que un usuario estaba interesado. Estas circunstancias hacen que un repositorio no contenga los mismos objetos de forma estática sino que evoluciona y cambia con el tiempo. Por lo tanto, es necesario encontrar un mecanismo que mantenga a los usuarios informados en aquellas materias que se actualizan o se incorporan a los repositorios y que son de su interés. Para resolver este problema planteamos un sistema federado de repositorios que integre un sistema multiagente encargado de informar al usuario de los cambios y las nuevas incorporaciones de objetos de aprendizaje que son de su interés.

Cuando un usuario realiza una búsqueda de determinados objetos de aprendizaje en un repositorio federado establece unos criterios de búsqueda generalmente basados en los campos de LOM más utilizados.

El sistema que proponemos le dará la oportunidad al usuario de guardar dichos criterios de búsqueda y un histórico con los resultados obtenidos. De esta forma se establecerá un sistema de avisos que se activará en el momento en que se detecte que se ha producido o bien un cambio en alguno de los objetos ya encontrados o bien la incorporación de nuevos objetos que coincidan con los criterios de búsqueda. También es importante señalar que si se produce la incorporación de nuevos repositorios al sistema federado automáticamente se revisarán para comprobar la existencia de objetos interesantes para el usuario.

El asunto abordado está presente en la propuesta arquitectónica que IMS presentó para promover la interoperabilidad entre repositorios [6], donde se describen 5 servicios básicos que los repositorios deberían proveer, uno de ellos es Alert/Expose que en la primera fase de la especificación se dejó sin concretar, haciendo únicamente referencia a que podría estar implementado por alguna agregación de servicios al repositorio y que el uso de SMTP podría satisfacer esta función. En el presente trabajo justamente se aborda un modelo para proveer este servicio.

Algunos trabajos proponen usar OAI-PMH en un escenario federado para notificar cambios en un repositorio dentro de la federación [7]. Este modelo tiene el inconveniente de que las notificaciones no se producen en el momento de producirse un cambio, sino en el momento en que una consulta OAI-PMH, programada periódicamente en algún agente produce resultados. Esto acarrea además un tiempo de procesamiento superfluo en el caso en que en el repositorio no haya habido ninguna modificación.

Para realizar esta tarea es muy adecuado el uso de agentes software, ya que como se ha visto en su descripción tendrían un objetivo a cumplir, que sería el de cubrir las necesidades de localización de contenidos docentes de unas determinadas características. Podemos decir que el agente utilizaría, de forma preactiva los datos de búsqueda para automatizar y optimizar la localización de contenidos docentes requeridos por el usuario, de un modo más rápido y eficiente que si el usuario realizara esta labor de forma continuada.

5.1 Desarrollo del Sistema

Para implementar este sistema se necesita incorporar un agente software en cada uno de los repositorios que agrupa el sistema federado, de esta forma cada agente guardará en una base de datos: los criterios de búsqueda de los usuarios de su repositorio y los metadatos de los objetos de aprendizaje encontrados con esos criterios de búsqueda. En el momento en el que se modifican los contenidos de los objetos de aprendizaje o se incorporan nuevos objetos de aprendizaje en cualquier repositorio, el agente debe comprobar la base de datos y activar el sistema de avisos a los usuarios. Para que esto se realice correctamente se debe programar la comunicación entre los agentes de forma que se notifiquen dichos cambios en los objetos de aprendizaje de un determinado repositorio al resto de agentes de los repositorios restantes (figura 1).

Figura 1. Sistema propuesto

Para saber si un objeto de aprendizaje se ha actualizado el agente tendrá que comprobar la modificación de dos de los campos LOM de la descripción de metadatos del objeto de aprendizaje que son “versión” y

“fecha”, si se ha producido un cambio en cualquiera de estos campos debemos comprobar que ese objeto le pueda interesar a los usuarios del sistema y por tanto avisarles.

Cuando se incorpora un nuevo objeto de aprendizaje en alguno de los repositorios el agente de ese repositorio debe comprobar los criterios de búsqueda de sus usuarios para ver si alcanzan un nivel adecuado de coincidencia esperada y comunicar al resto de agentes los metadatos del nuevo objeto con el fin de que estos hagan sus comprobaciones pertinentes.

5.2 Funcionamiento del Sistema

El sistema federado está organizado como una red P2P, donde los participantes a veces actúan como clientes solicitando contenido y otras como servidores, despachando las solicitudes que les llegan.

El sistema de alertas necesita implantar en cada nodo del sistema un componente que permita difundir los eventos producidos en el repositorio local al resto de la federación y otro componente que permita procesar las alertas que lleguen desde los demás nodos de la federación. De esta forma sobre el sistema existente se va a superponer otro sistema con naturaleza P2P donde cada nodo actúa a veces difundiendo alertas y otras procesándolas. La figura 2 muestra esta primera aproximación a la arquitectura del sistema. El componente que difunde los eventos se ha llamado Despachador de Alertas (DA) y al componente que las recibe Consumidor de Alertas (CA).

Figura 2. Arquitectura simplificada del sistema

Los eventos se producen dentro del repositorio de forma que es necesario conducirlos desde allí hasta el DA. En concreto los eventos en que estamos interesados los producen los autores de contenido, ya sea insertando nuevos objetos o modificando los existentes. Los autores utilizan algún tipo de interfaz de usuario (UI) para acceder a los servicios de publicación del repositorio. Con toda generalidad se puede pensar que una tarea de publicación de un objeto involucra, entre otras, a una capa de interfaz de usuario que suele tratarse de un componente Web, donde es posible rastrear las acciones del usuario. La labor del Consumidor de Eventos Interno (CEI) consistiría en capturar los eventos adecuados producidos en el contenedor Web y conducirlos hacia el DA para que este los distribuya entre los CA de la federación (figura 3). El diseño de este consumidor depende de la arquitectura interna de cada repositorio. En la mayor parte de los repositorios de código libre investigados es posible implantar este modelo. Por ejemplo DOOR esta implementado en PHP y en DSpace [8] y Fedora los interfaces de usuario están implementados como contenedores Web de JEE. La especificación Servlet, contenida dentro de JEE define objetos a propósito para recibir notificaciones del componente Web, los “Listener”.

Figura 3. Interacción Consumidor-DA

Para el prototipo desarrollado se ha utilizado DSpace. DSpace posee su propio sistema de eventos que posee una granularidad completamente adecuada al propósito de este trabajo: permite distinguir la creación, instalación, modificación de nuevos objetos o de sus metadatos. DSpace llama consumidores a los objetos interesados en recibir notificaciones de eventos. Un consumidor debe implementar el interfaz Consumer, que describe métodos adecuados por donde entregar el contexto del evento sucedido; el consumidor se debe registrar en el archivo de configuración de DSpace dspace.cfg.

Tanto los CA como los DA forman parte de una misma plataforma de agentes distribuidos en contenedores a través de la federación. Debe existir un contenedor al menos en cada repositorio albergando a su CA y DA. Los contenedores están coordinados por un contenedor principal donde reside un registro de los servicios de alerta desplegados en la federación.

Cuando un CA está interesado en recibir notificaciones de eventos debe empezar por contactar con el registro para localizar los DA disponibles y después suscribirse a cada uno de ellos como se muestra en la figura 4.

Figura 4. Actividad del CA

El contenedor principal debería además notificar la aparición o supresión de nuevos contenedores o mejor aún de los DA para que el resto de contenedores pueda suscribirse a sus servicios.

Las preferencias de los clientes de cada repositorio residen en una BBDD a la que deben acceder los CA cuando reciben una notificación de los DA del repositorio. El acceso se hace mediante un DAO que expone servicios para obtener objetos representantes de las preferencias de los clientes.