The implementation of an intermediate middleware layer between the LMS platform and contents is described. It allows updating the functionalities of LMS and integrating new services. The model is based on SCORM architecture and the extensibility properties of standard vocabularies. An application has been implemented at “Centro de Formación Virtual” of Renfe, to adapting their proprietary LMS to the standard, allowing the integration of compatible courses with the minimal developing effort.
Conforme se asienta el uso de las técnicas de e-learning, tanto a nivel empresarial
como universitario, se pone de manifiesto la importancia de potenciar la
“reutilización” de los contenidos en diferentes contextos. Existen distintas definiciones para el
concepto objeto de aprendizaje [
La creciente industria de producción de contenidos de e-learning refleja estas situaciones, así como la progresiva aceptación de los estándares en la práctica. La garantía para los responsables de compras de contenidos de las grandes corporaciones se centra en la estricta adecuación a las normas. Ello les asegura una fácil integración en las infraestructuras de que disponen. Así, los productores de contenidos deben ser en extremo cuidadosos con dichos requerimientos, incluso aunque consideren que en algunos casos pueda quedar limitada su creatividad [7].
Será esencial a corto plazo que la evolución de los sistemas se realice en paralelo
por parte de contenidos y plataformas. Es necesario actualizar las plataformas para
poder disponer de los contenidos más modernos y didácticos. Es necesario que los
creadores de contenidos utilicen la potencialidad de los estándares y su trabajo sea
soportado por las plataformas. Todos estos cambios implican problemas de
compatibilidad. Un posible enfoque para solucionar algunos de estos problemas se desarrolla
en este artículo, sobre el caso particular de la adaptación de una plataforma LMS al
estándar SCORM 1.2 [
Se propone una arquitectura de software para dotar a los contenidos y/o plataformas de un conjunto extensible de servicios. La solución planteada consiste en la creación de una capa de software intermedio, o middleware, alojada en el cliente web (navegador), que monitorice las comunicaciones entre contenidos y plataforma y aporte en cada caso las funcionalidades necesarias. Estas se estructuran en distintos módulos independientes, pero siempre bajo un API común, pues es la mejor manera de aportar la infraestructura necesaria para alojar múltiples desarrollos generalistas o específicos, ya que cada proyecto tiene sus propios condicionantes.
Se busca con ello ofrecer una base sobre la que resolver problemas de
compatibilidad o construir nuevas funciones no estándar de una manera coherente, flexible y
sistemática. Sobre esta arquitectura puede implementarse distintas soluciones
propietarias para cada caso o problema, siempre con el objetivo de minimizar el esfuerzo de
desarrollo, potenciar la reutilización del código y abaratar los costes de producción,
aportando las máximas facilidades para los autores [
La solución propuesta se basa en la distribución del software de e-learning en tres capas: plataforma Ù middleware Ù contenidos . Plataforma y contenidos están muchas veces sujetos a la actualización y dependencia del fabricante, a los estándares y a los costes y requerimientos del equipo de producción. La inclusión de una capa intermedia aporta flexibilidad en el punto de “unión” de ambos entornos.
A nivel conceptual, el middleware actúa como un filtro de las llamadas estándar entre plataforma y contenidos, por ejemplo las definidas por el Runtime API de SCORM. Si es necesario se puede extender el número de llamadas: las que sean para la plataforma, las transmitirá a la plataforma, realizando la adaptación pertinente. Las que impliquen funcionalidades ampliadas, las ejecutará por sí mismo.
El middleware actúa en diferentes ámbitos: 1. Extiende y/o simula las funcionalidades del RUNTIME API de SCORM. El middleware ofrece a los contenidos el interfaz y llamadas definidas por el estándar. SCORM describe un conjunto de funciones de interacción que los contenidos ejecutan para realizar tareas como inicializar, finalizar o intercambiar información con la plataforma. El concepto de middleware permite el uso generalista de este vocabulario, así como su extensión, implementando nuevas funciones que los contenidos pueden utilizar de manera transparente a la plataforma. De este modo, si se está utilizando una plataforma compatible, el middleware desviará a la plataforma las llamadas que le correspondan, enviando las respuestas directamente a los contenidos. Si no se dispone de plataforma compatible, se navega off-line o se añade funcionalidades en forma de vocabulario extendido, el middleware responderá por sí mismo, en función de su implementación particular y de su adaptación a cada plataforma.
2. Permite a los contenidos el acceso a sus metadatos. Por otro lado, el middleware puede disponer de acceso a los documentos XML definidos por el estándar. El manifiesto es el fichero que contiene la estructura del curso, los datos de navegación y la lista de recursos utilizados. Los metadatos añaden información a los objetos de aprendizaje. En el estándar no se prevé un mecanismo para otorgar a los contenidos el acceso a sus propios metadatos, aunque ello puede ser de gran utilidad. Por ejemplo, permite desarrollar funciones para informar al alumno de su posición en la ruta de navegación, o para ofrecer de manera sistematizada resúmenes de cada objeto de aprendizaje, o información sobre el autor. Para todos estos supuestos, es necesario que desde el cliente web se acceda a los metadatos. Además, no hay que olvidar que el estándar SCORM aporta mecanismos de extensión de los metadatos, usando nombres de espacio XML; ello permite a los desarrolladores incluir información propia, manteniendo la compatibilidad.
3. Actúa sobre los contenidos de manera descendente. El middleware puede actuar también sobre los propios contenidos implementando funcionalidades específicas. Este mecanismo no está definido en el estándar, donde las funciones siempre son ascendentes, es decir, las funciones son siempre llamadas por los contenidos. El middleware es una implementación propietaria, por tanto puede alojar módulos con implementaciones particulares de un autor, para contenidos específicamente preparados. Es el procedimiento normal de los diseñadores web cuando incluyen scripts de otros autores con menús o utilidades prediseñadas en sus páginas. El middleware ofrece así una manera sencilla de encapsular estas utilidades, permitiendo incluso mantener el código inaccesible, pero proporcionando un interfaz organizado.
Los tres ámbitos de actuación descritos, si se combinan adecuadamente, aportan una infraestructura que los desarrolladores pueden utilizar para resolver muchos problemas y organizar sus aplicaciones. Tanto vendedores de plataformas como creadores de contenidos pueden usar esta solución, presentando el middleware bien como un plug-in de la plataforma, bien como plug-in de los contenidos, o bien como elemento con entidad propia.
El middleware se ejecuta en el equipo cliente y se ha diseñado para trabajar sobre el estándar SCORM. Dependiendo del navegador y los requerimientos técnicos de las funcionalidades a implementar, puede desarrollarse con distintas tecnologías, por ejemplo Javascript, Java, ActiveX o Macromedia Flash.
El Middleware se integra en el frame superior a los contenidos, dentro de la estructura de frames definida por la plataforma. Los contenidos compatibles con SCORM tratarán de localizar un objeto javascript denominado “runtime API”, y encontrarán al middleware. A su vez, el middleware deberá localizar el “runtime API” entregado por la plataforma, si es que esta es compatible con el estándar.
En algunos casos, el middleware necesitará comunicarse con la plataforma o su sistema de base de datos en modo propietario. Puede programarse la lógica necesaria en el servidor, específica para cada plataforma, en los entornos de desarrollo más comunes: ASP.NET, PHP, JSP, o Coldfusion. Preferiblemente, el middleware se comunicará con esta capa de lógica mediante el uso de servicios web. De este modo, se aísla en lo posible las particularidades, minimizando el esfuerzo de desarrollo.
Una implementación de la idea descrita en este artículo se ha desarrollado para el Centro de Formación Virtual de Renfe, plataforma de e-learning gestionada por el de Centro de Formación Tecnológica de Renfe en Valencia.
El prototipo permite, en una primera fase, incluir contenidos SCORM 1.2 en una plataforma LMS desarrollada a medida según el modelo formativo y la estructura administrativa de la empresa, pero que no estaba adaptada al estándar.
Mediante la inclusión de un módulo de middleware se implementa una versión en Javascript del RUNTIME API SCORM 1.2, que contempla las llamadas que el estándar define como obligatorias para cualquier plataforma. Las llamadas al API son gestionadas por el middleware y los datos necesarios almacenados mediante cookies en el ordenador del alumno, de este modo no es necesario modificar el código de la plataforma, el sistema de tracking, ni ampliar la estructura de base de datos; sin embargo, se provee a los contenidos de toda la funcionalidad necesaria. La plataforma utiliza ventanas de pop-up para mostrar los contenidos; tras el análisis se determina que el middleware debe alojarse en el “frameset” superior de dichas ventanas.
La principal desventaja de este diseño es que la plataforma no tiene acceso a la información SCORM, ya que cada alumno funciona independientemente y desde un único PC; así, la plataforma mantiene su sistema de seguimiento propietario, que controla el acceso de los alumnos. Como principal ventaja, destacar la facilidad de integración: en el plazo de mes y medio y con un coste mínimo de desarrollo, la plataforma consigue integrar los contenidos de distintos fabricantes del mercado. En la figura 3 se aprecia el aspecto de uno de los prototipos realizados.
En las siguientes fases del proyecto se ha abordado la integración de la información SCORM en la plataforma, estableciendo un sistema de comunicación con el middleware mediante el uso de servicios web, que se implementan en la plataforma mediante las herramientas que ofrece Macromedia ColdFusion, lenguaje nativo de la misma. Se da soporte además al modelo SCORM completo, para incluir el sistema de tests y evaluaciones. En este caso, el middleware se implementa en Macromedia Flash y utiliza servicios web para comunicarse con la plataforma.
Se ha descrito en este artículo una arquitectura de middleware que permite extender los mecanismos de comunicación entre contenidos y plataforma, solucionar problemas de compatibilidad e incluir información y funcionalidades ampliadas. El middleware es modular y actúa en distintos ámbitos, extendiendo el estándar, accediendo a los metadatos de los contenidos y ofreciendo soporte para el desarrollo de módulos de utilidades. A partir de esta idea, se ha implementado un módulo que en un corto tiempo de desarrollo ha permitido a la plataforma del Centro de Formación Virtual de Renfe alojar contenidos compatibles con el estándar SCORM 1.2. Las siguientes fases del proyecto adaptarán la plataforma por completo al estándar.