ARQUITECTURA DISTRIBUIDA DE E-LEARNING BASADA EN …
120
ARQUITECTURA DISTRIBUIDA DE E-LEARNING BASADA EN SERVICIOS WEB GABRIEL JOSE GIRALDO NAVARRO UNIVERSIDAD DE LOS ANDES DEPARTAMENTO DE INGENIERIA DE SISTEMAS Y COMPUTACION MAGISTER EN INGENIERIA DE SISTEMAS Y COMPUTACION BOGOTA D.C. 2004
Transcript of ARQUITECTURA DISTRIBUIDA DE E-LEARNING BASADA EN …
ARQUITECTURA DISTRIBUIDA DE E-LEARNING
BASADA EN SERVICIOS WEB
GABRIEL JOSE GIRALDO NAVARRO
UNIVERSIDAD DE LOS ANDES DEPARTAMENTO DE INGENIERIA DE SISTEMAS Y COMPUTACION
MAGISTER EN INGENIERIA DE SISTEMAS Y COMPUTACION BOGOTA D.C.
2004
ARQUITECTURA DISTRIBUIDA DE E-LEARNING
BASADA EN SERVICIOS WEB
GABRIEL JOSE GIRALDO NAVARRO
Proyecto de grado para optar al título de Magíster en Ingeniería de Sistemas y Computación
Director FRANCISCO RUEDA
UNIVERSIDAD DE LOS ANDES DEPARTAMENTO DE INGENIERIA DE SISTEMAS Y COMPUTACION
MAGISTER EN INGENIERIA DE SISTEMAS Y COMPUTACION BOGOTA D.C.
2004
Nota de aceptación:
El presente documento cumple con los
requisitos académicos y metodológicosexigidos por el programa de Magíster en
Ingeniería de Sistemas y Computaciónde la Universidad de los Andes
Francisco Rueda Director
Claudia Jiménez Jurado
Luz Adriana Osorio Jurado
Alfredo Hernández Jurado Externo
Bogotá D.C., 5 de Febrero de 2004
A Gabriel y Leonor, mis padres, a quienes debo todo lo que soy.
A Dayana, mi novia, mi fuente diaria de inspiración.
AGRADECIMIENTOS
El autor expresa su más sincero agradecimiento a su familia, por todo el apoyo brindado
durante toda la maestría; a Francisco Rueda, Claudia Jiménez y Luz Adriana Osorio,
quienes como Director y Jurados en la Universidad de los Andes de este proyecto de
grado contribuyeron con sus valiosos aportes con el feliz término del mismo; a Alfredo
Hernández y a la empresa AprendaHaciendo, por toda la colaboración prestada durante el
desarrollo de esta tesis.
TABLA DE CONTENIDO
INTRODUCCION..................................................................................................................1 OBJETIVOS .........................................................................................................................5 1. MARCO TEORICO...........................................................................................................6
1.1. LAS SOLUCIONES DE E-LEARNING .................................................................6 1.1.1. Características principales............................................................................8 1.1.2. Componentes básicos de una solución de e-Learning .................................9 1.1.3. Evolución Tecnológica ................................................................................11 1.1.4. Los objetos de aprendizaje (Learning Objects) ..........................................13 1.1.5. Los ambientes LMS (Learning Management System)................................16
1.2. LA INICIATIVA ADL Y EL MODELO DE REFERENCIA SCORM......................18 1.2.1. El Modelo de Agregación de Contenido .....................................................20 1.2.2. El Ambiente de Ejecución de SCORM........................................................30
1.3. LOS SERVICIOS WEB.......................................................................................31 1.3.1. Antecedentes ..............................................................................................31 1.3.2. ¿Qué son los servicios web? ......................................................................34 1.3.3. Arquitectura de los servicios web ...............................................................36 1.3.4. Estándares de los servicios web.................................................................39 1.3.5. Los Servicios Web Interactivos...................................................................41
2. LOS SERVICIOS WEB DE E-LEARNING.....................................................................47 2.1. MOTIVACION .....................................................................................................47 2.2. DEL PAQUETE DE CONTENIDO SCORM AL SERVICIO WEB.......................51 2.3. BENEFICIOS......................................................................................................53 2.4. CARACTERISTICAS DE UNA ARQUITECTURA DE SERVICIOS WEB DE E-LEARNING..................................................................................................................55
2.4.1. Los proveedores de soluciones de e-Learning como servicios Web..........56 2.4.2. Los intermediarios o servicios de directorio................................................62 2.4.3. Los consumidores de los servicios web de e-Learning ..............................68
3. DISEÑO E IMPLEMENTACION..................................................................................77 3.1. DISEÑO DE LA SOLUCION...............................................................................77
3.1.1. Diseño de la arquitectura de los proveedores de e-Learning .....................77 3.1.2. Diseño de la arquitectura del directorio de servicios de e-Learning ...........82 3.1.3. Diagrama de Deployment ...........................................................................89
3.2. IMPLEMENTACION DE LOS SERVICIOS WEB DE E-LEARNING...................90 3.2.1. Ambiente de Desarrollo ..............................................................................91 3.2.2. Implementación de un servicio web de contenido ......................................92 3.2.3. Implementación de un servicio web interactivo de evaluación ...................94 3.2.4. Implementación de un Curso Dinámico de Excel basado en Servicios Web .............................................................................................................96 3.2.5. Implementación de un servicio de directorio de e-Learning .......................98
4. CONCLUSIONES .....................................................................................................101 BIBLIOGRAFIA ................................................................................................................103 ANEXOS ..........................................................................................................................106
TABLA DE FIGURAS
Figura 1. Evolución Tecnológica del e-Learning ...............................................................12 Figura 2. Elementos interdependientes de una arquitectura de Learning Objects.............15 Figura 3. Modelo Generalizado de un Sistema de Administración de Aprendizaje............17 Figura 4. Ejemplos de activos (assets)...............................................................................21 Figura 5. Agregación de Contenido en SCORM ................................................................22 Figura 6. Metadatos XML de un SCO ................................................................................26 Figura 7. Diagrama conceptual de un paquete de contenido SCORM ..............................27 Figura 8. Ejemplo de un manifiesto XML de un paquete de contenido SCORM................29 Figura 9. Arquitectura Orientada al Servicio.......................................................................38 Figura 10. Servicios Web Orientados a la Presentación vs. Servicios Web Orientados a los Datos .................................................................................................................................43 Figura 11. Proceso de creación y distribución de SCOs....................................................48 Figura 12. Evolución del paquete de contenido SCORM al Servicio Web........................52 Figura 13. Soluciones globales de e-Learning ...................................................................54 Figura 14. Ejemplo del uso de un servicio web interativo de evaluaciones .......................60 Figura 15. ¿Cómo funciona UDDI? ....................................................................................63 Figura 16. Uso de un motor de búsqueda sobre UDDI especializado para facilitar la ubicación de servicios web de e-Learning..........................................................................66 Figura 17. Búsqueda dinámica de contenido e-Learning...................................................70 Figura 18. Integración a Sistemas de Información Organizacionales ................................72 Figura 19. Necesidad de aplicaciones auxiliares para LMS, durante la fase de introducción de los servicios de e-Learning............................................................................................75 Figura 20. Escenario futuro de los LMS con funcionalidades para consumir directamente servicios web y ensamblar soluciones personalizadas bajo demanda ..............................75 Figura 21. Arquitectura lógica por capas del Proveedor de e-Learning .............................79 Figura 22. Paquetes Metadata y ServicioWebContenido...................................................81 Figura 23. Diagrama de clases del Paquete ServicioWebContenido.................................81 Figura 24. Diagrama de clases del Paquete Metadata ......................................................82 Figura 25. Arquitectura lógica por capas del Directorio de Servicios Web de e-Learning .83 Figura 26. Paquetes principales del directorio de servicios de e-Learning ........................84 Figura 27. Diagrama de clases del Paquete Registro ........................................................85 Figura 28. Diagrama de clases del Paquete Indexacion ....................................................86 Figura 29. Diagrama de clases del Paquete Crawler .........................................................86 Figura 30. Diagrama de clases del Paquete ServicioWebConsulta ...................................87 Figura 31. Diagrama de secuencia del "crawling" de servicios web de e-Learning ...........88 Figura 32. Diagrama de despliegue físico de los componentes participantes en la arquitectura de servicios web de e-Learning......................................................................89 Figura 33. Arquitectura de la Plataforma WebCollage Syndicator for Portlets.................109
TABLA DE ANEXOS
ANEXO 1. CARACTERÍSTICAS TECNICAS DE LA HERRAMIENTA WEBCOLLAGE SYNDICATOR..................................................................................................................107 ANEXO 2. ¿QUÉ ES APRENDAHACIENDO?.................................................................110 ANEXO 3. DESCRIPCIÓN DEL CONTENIDO DEL CD QUE ACOMPAÑA A ESTE DOCUMENTO..................................................................................................................111
MISC-03-1-8
1
INTRODUCCION
El e-Learning, o el aprendizaje a través de tecnologías de información, ha venido
evolucionado con grandes pasos en los últimos años y su potencial de capacitación o
entrenamiento de individuos de una manera flexible, independiente del lugar y del tiempo,
ha sido visto con buen interés por parte de organizaciones con actividades de negocio de
diversa naturaleza, además de las instituciones académicas, como universidades y
colegios, como complemento a la enseñanza guiada por un profesor en un aula de clases.
A lo largo de esta evolución, se han desarrollado diferentes metodologías y tecnologías
para llevar los contenidos instruccionales a los estudiantes: desde un sencillo CD-ROM
que contiene la aplicación de e-Learning con la que el individuo debe interactuar, hasta
los ambientes LMS1 existentes en la actualidad en los que, a través de interfaces web, se
ha permitido la administración de los procesos de capacitación de los individuos de una
organización, permitiendo gestionar tanto el contenido de los cursos de e-Learning que se
deben tomar, como la participación de los estudiantes alrededor de los mismos a través
de actividades como la inscripción a cursos, evaluaciones de conocimiento, seguimiento
de los participaciones, etc.
Estas soluciones de e-Learning son generalmente desarrolladas por diferentes
proveedores con herramientas especializadas para la generación de contenido
instruccional, y luego distribuidas a las organizaciones interesadas: un CD-ROM es
enviado, una dirección de un sitio web es suministrada o un paquete de un LMS es
facilitado, por ejemplo.
Sin embargo, hoy en día, debido a la movilidad y dinámica de los negocios, se requiere de
soluciones novedosas de aprendizaje: disponibles en el instante y lugar en que sean
necesarias, adaptadas a las necesidades particulares de los individuos en ese preciso
momento y preferiblemente integradas a los sistemas con que las personas se
1 Learning Management System: Sistemas de Administración del Aprendizaje
MISC-03-1-8
2
desenvuelven con el fin de hacer la experiencia de aprendizaje, en lo posible,
transparente y natural para el o ella.
En su mayoría, las soluciones de aprendizaje actuales son construidas con una estructura
de contenido estática, sin capacidades de adaptación a las necesidades particulares de
los estudiantes en un determinado momento, y mucho menos de integración con los
sistemas corporativos.
Por lo tanto, para satisfacer las necesidades de los negocios de soluciones novedosas de
aprendizaje mencionadas, es necesaria la descripción de una arquitectura de e-Learning
que cumpla con las siguientes características:
• Los elementos de una solución deben poder ser ensamblados de acuerdo con las
necesidades particulares de los individuos en un determinado instante.
• Las soluciones de e-Learning deben poder ser descritas de una manera estándar
para poder garantizar el entendimiento de su estructura desde cualquier
aplicación, sin importar sus características tecnológicas.
• Las soluciones de e-Learning deben poder ser integradas a diversos sistemas o
aplicaciones con el fin de hacer transparente y natural la experiencia de
aprendizaje al estudiante
• Los mecanismos de distribución de las soluciones de e-Learning deben ser
flexibles para adaptarse a la dinámica actual de los negocios
Además, es importante que la descripción de una arquitectura que satisfaga las anteriores
necesidades sea independiente de cualquier metodología de diseño instruccional, con el
fin de hacerla adaptable a diferentes escenarios pedagógicos.
La primera inquietud sobre la adaptación de las soluciones de aprendizaje a las
necesidades del individuo ya ha sido analizada por expertos en la materia y ha dado
nacimiento al concepto de los Learning Objects2 [EDUWORKS, 03], una estrategia en la
cual el contenido es dividido en elementos más pequeños, con el fin de que puedan ser
2 Objetos de Aprendizaje
MISC-03-1-8
3
separados y unidos de muchas maneras diferentes (dependiendo del contexto en que se
necesiten).
La segunda inquietud también ha sido tratada por la industria del e-Learning.
Precisamente, en noviembre de 1997, el Departamento de Defensa de Estados Unidos y
la White House Office of Science and Technology Policy (OSTP) dieron inicio a la
iniciativa de aprendizaje distribuido avanzado ADL 3 con el propósito de “asegurar el
acceso a materiales educativos y de entrenamiento de alta calidad, que pudieran ser
construidos de acuerdo con las necesidades individuales de cada estudiante y estuvieran
disponibles en el momento y lugar en que fueran necesarios…[Con este pensamiento en
mente, su objetivo fue lograr una estandarización del e-Learning:] desarrollar un conjunto
de especificaciones que permitan la reutilización, accesibilidad, durabilidad e
interoperabilidad del contenido de las soluciones de aprendizaje” [ADL, 2001]. Este
conjunto de especificaciones es lo que se conoce hoy en día como el modelo de
referencia SCORM4, creado con el fin de garantizar que las soluciones de e-Learning, sin
importar las herramientas con las que sean creadas, puedan ser utilizadas a través de
diferentes ambientes de aprendizaje LMS.
Las últimas dos inquietudes (facilidad de integración y flexibilidad de distribución) han sido
tradicionalmente parte de la problemática del desarrollo de aplicaciones distribuidas en
Internet. Ni el concepto de los objetos de aprendizaje, ni la estandarización lograda con
SCORM brindan alguna aproximación a la solución de esta problemática en lo que refiere
a las soluciones de e-Learning. Sin embargo, Internet se ha ido transformando y gracias a
la necesidad de interoperabilidad en los procesos de negocios entre diferentes
organizaciones a través de la web, así como la evolución de tecnologías relacionadas con
la computación distribuida, han sido definidos un grupo de estándares y una arquitectura
que ha dado origen a un nuevo modelo conocido como servicios web (o Web Services):
servicios interoperables que pueden ser invocados desde cualquier aplicación,
independiente de la plataforma, en cualquier momento y lugar.
3 Advanced Distributed Learning (http://www.adlnet.org) 4 Shareable Content Object Reference Model (Modelo de Referencia de Objetos de Contenido Compartibles) (http://www.adlnet.org/index.cfm?fuseaction=scormabt)
MISC-03-1-8
4
¿Cómo pueden ser aplicados los servicios web en el e-Learning para la creación de estas
soluciones novedosas de aprendizaje necesitadas por los negocios de hoy en día?
Este documento pretende mostrar que, como aproximación para la solución de las dos
últimas inquietudes mencionadas, los servicios web constituyen la pieza restante para el
nuevo modelo de aplicaciones de e-Learning requerido.
Esta tesis pretende recoger los esfuerzos de estandarización desarrollados alrededor de
los servicios web y el modelo de referencia SCORM (junto al concepto de los objetos de
aprendizaje), y presentar un nuevo enfoque de una arquitectura de e-Learning basada en
los anteriores elementos para la creación de soluciones innovadoras de e-Learning que
permitan que los usuarios obtengan experiencias de aprendizaje ubicuas, dinámicas,
transparentes y adaptadas a sus necesidades.
MISC-03-1-8
5
OBJETIVOS
Objetivo General
• Identificar y describir los principales componentes de una arquitectura de Servicios
Web en Internet como una nueva alternativa tecnológica para el desarrollo de
soluciones de e-Learning.
Objetivos Específicos
• Investigar las principales características del nuevo modelo de los Servicios Web
para el desarrollo de aplicaciones distribuidas sobre Internet.
• Conceptualizar sobre los ambientes de e-Learning y sus características.
• Investigar sobre los esfuerzos de estandarización que la industria del e-Learning
ha llevado a cabo en los últimos años.
• Basado en las anteriores investigaciones, describir una propuesta basada en
servicios web que ilustre un nuevo enfoque para la creación de aplicaciones o
soluciones de e-Learning.
• Implementar un prototipo que ejemplifique un ambiente de e-Learning basado en
servicios web, de acuerdo con la propuesta realizada.
MISC-03-1-8
6
1. MARCO TEORICO
1.1. LAS SOLUCIONES DE E-LEARNING El surgimiento de Internet y los posteriores avances alrededor del mismo han creado un
ambiente bastante prometedor para la tecnología y la educación. Los contenidos en línea
ofrecen un ambiente instruccional basado en la tecnología que permite que las
oportunidades de aprendizaje se expandan y que se mejore la calidad de la educación a
través de una variedad de formatos y modalidades. Con las necesidades actuales de los
individuos, que necesitan un ambiente continuo de educación o capacitación, los
programas de e-Learning ofrecen una solución a los conflictos entre el trabajo, la familia y
el estudio, entre otros.
Por e-Learning se entiende la “aplicación de las tecnologías de información y de
comunicación al aprendizaje formal e informal” [ALIN, 03]: un ambiente en el cual el
contenido instruccional o las experiencias de aprendizaje son distribuidas o habilitadas por
las tecnologías electrónicas [CTAL, 01]. Puede incluir una amplia variedad de estrategias
y tecnologías de aprendizaje, desde CD-ROM y CBT5 hasta videoconferencias, difusión
satelital y redes educativas virtuales. El objetivo principal es el “intercambio de
información y la obtención de conocimiento” [CTAL, 01].
Estos ambientes en línea ofrecen oportunidades sin precedentes para personas que de
otra forma tendrían un acceso limitado a los diferentes contenidos, así como un nuevo
paradigma en el cual cursos dinámicos y de una mejor calidad pueden ser desarrollados.
Entre los beneficios que tienen las soluciones de e-Learning se encuentran [THEBOARD,
01]:
5 Computer Based Training (Entrenamiento basado en Computador)
MISC-03-1-8
7
• Independencia de Lugar y Tiempo: La primera ventaja del e-Learning es que
permite a los individuos ser partícipes de los diferentes contenidos, sin importar los
problemas de distancia ni de tiempo existentes. El e-Learning proporciona el
entrenamiento necesario para los estudiantes cuando y donde lo necesiten.
• Centrado al estudiante: En algunas propuestas pedagógicas, los mismos
individuos partícipes del contenido tienen el control sobre su proceso de
aprendizaje, extrayendo de manera personalizada la información que más se
ajusta a sus necesidades.
• Énfasis en las soluciones y los resultados: En el área laboral, el entrenamiento
está dando paso a soluciones de aprendizaje, en las cuales el acceso a la
información en el instante deseado es de gran importancia. Esta integración del e-
Learning con el trabajo permite mejorar el desempeño en una forma interactiva y
dinámica.
• Enseñanza creativa: La naturaleza autónoma y autodirigida de estos ambientes de
aprendizaje permiten y necesitan de enfoques innovadores y creativos en los
procesos de enseñanza.
Sin embargo, también existen algunas debilidades dentro de las mismas soluciones de e-
Learning [THEBOARD, 01]:
• En los estudiantes: La flexibilidad y el control sobre el proceso de aprendizaje que
los individuos adquieren gracias al e-Learning, coloca una gran responsabilidad
sobre los mismos. El aprendizaje en línea requiere generalmente de organización,
auto-motivación y buena administración del tiempo con el fin de cumplir los
objetivos de los cursos.
• En las instituciones: La falta de presencia física (como en la enseñanza tradicional)
debe ser compensada por un ambiente en el cual los individuos se sientan
motivados a participar y conozcan claramente en dónde acceder el contenido que
MISC-03-1-8
8
necesitan. El éxito en la enseñaza tradicional no garantiza el mismo en la
instrucción en línea.
• No todos los temas son aptos: El estado actual de desarrollo del medio y las
herramientas de difusión del contenido no permiten que temas como la cirugía, la
expresión oral, los deportes, entre otros donde el movimiento físico y la práctica
constituyen los objetivos del aprendizaje, puedan ser enseñados en línea. Sin
embargo, si bien lo anterior es cierto en el campo práctico, en un concepto más
amplio de aprendizaje el e-Learning si puede brindar un espacio de aprendizaje
adecuado en cualquier área del conocimiento, por ejemplo para la
conceptualización de sus contenidos.
• En el contenido: Con el fin de que un programa de aprendizaje en línea sea
exitoso, el contenido debe ser cuidadosamente considerado y desarrollado.
Además, este no necesariamente es el único componente de un ambiente de
aprendizaje exitoso, como se mencionará más adelante.
Como se menciona en [OBRINGER, 02], de estos beneficios y debilidades se puede
concluir que “la calidad del entrenamiento electrónico, al igual que todas las formas de
entrenamiento, se basa en su contenido y su distribución. El e-Learning puede sufrir de
los mismos males de la enseñanza en el salón de clases…Sin embargo, la belleza del e-
Learning es que cada nuevo software permite la creación de ambientes efectivos de
aprendizaje“, siempre y cuando este software esté apoyando un propósito o una
motivación de enseñanza, una propuesta pedagógica, una metodología instruccional,
brinde diversos medios para la exploración de los recursos de aprendizaje desarrollados,
y permita la evaluación y retroalimentación de los objetivos propuestos.
1.1.1. Características principales Dentro de las principales características de los ambientes o soluciones de e-Learning
podemos enumerar las siguientes:
MISC-03-1-8
9
• Constituyen un mecanismo de aprendizaje no lineal: Los usuarios (estudiantes)
pueden navegar por los diferentes temas del contenido dependiendo de sus
requerimientos, experiencia o contexto [ELEARNING, 03].
• El proceso de aprendizaje es auto-administrable: lo cual da origen al concepto de
aprendizaje justo a tiempo (Just-In-Time), es decir, el estudiante hace uso de los
contenidos instruccionales en el momento que desee y cuando sea necesario
[ELEARNING, 03].
• Crean nuevos modelos para la provisión del aprendizaje, diferentes a los utilizados
tradicionalmente en el aula de clases. “Un ambiente de e-Learning exitoso, lo es
técnica y pedagógicamente” [MARTINEZ, 02].
• Generalmente los contenidos pueden ser personalizados y el progreso posterior
puede ser monitoreado, soportado y evaluado, en parte gracias a la Web pues
ofrece la tecnología perfecta y un ambiente de aprendizaje en el que los individuos
pueden ser identificados de manera única [MARTINEZ, 02].
• Buscan la construcción de ambientes de aprendizaje que se adapten a las
diferencias individuales, asimismo como “el diseño y presentación de contenidos
instruccionales que reconozcan, concuerden y soporten la forma como los
individuos quieran y pretendan aprender de manera diferente” [MARTINEZ, 02].
1.1.2. Componentes básicos de una solución de e-Learning
Un ambiente efectivo de aprendizaje está basado en objetivos medibles que impacten las
habilidades del individuo usando contenido, interacción y retroalimentación. Por lo tanto,
en general todas las soluciones de e-Learning están conformadas por los siguientes tres
elementos básicos:
MISC-03-1-8
10
• Contenido Instruccional: Es la propiedad intelectual y el conocimiento que va a ser
impartido a los estudiantes. Puede ser representado en un número diferente de
formatos: texto, imágenes, animaciones, audio, video o simulaciones, entre otros
[ELEARNING, 03]. Es quizás el componente principal de todo ambiente de e-
Learning, El diseño del contenido de e-Learning debe ser articulado y coherente
con el modelo pedagógico seleccionado y tener significado para el estudiante,
sobre todo cuando este puede ser distraído por múltiples obligaciones (trabajo y
familia)
• Actividades colaborativas: La colaboración es un proceso para compartir
información entre partes interesadas de tal forma que ambas se beneficien
teniendo una comprensión más global de sus problemas e inquietudes. En su
forma más simple, puede ser simplemente el intercambio de información. En un
nivel más avanzado, incluye la unificación de contenido y procesos comunicativos,
y el establecimiento de foros para el acceso de recursos y la construcción de
contenido de valor agregado [SIEMENS2, 03].
El conjunto de métodos instruccionales que conforman el aprendizaje colaborativo
busca motivar a los estudiantes a trabajar en grupo en tareas académicas. Por lo
tanto, además del contenido se incluyen preguntas para discusión y respuestas
entre grupos de estudiantes. “Las estrategias de aprendizaje colaborativo…son
necesarias con el fin de que los cursos en línea sean tan efectivos como los
tradicionales” [HILTZ, 03].
En materia tecnológica, existen diferentes herramientas que facilitan la provisión
de un ambiente colaborativo fácil de utilizar: herramientas síncronas como las
audioconferencias, videoconferencias, chat, mensajería instantánea, tableros
electrónicos; y herramientas asíncronas como los foros de discusión, los anuncios
de grupo o el e-mail [KAPLAN, 02].
• Assessment y evaluaciones: Estos dos elementos deben ser diseñados de
manera diferente al enfoque utilizado tradicionalmente en los salones de clase, en
MISC-03-1-8
11
el que los exámenes y ensayos tienen una mayor preferencia. Con un ambiente de
enseñanza en línea se tienen nuevas alternativas de evaluación, a su vez más
efectivas y flexibles a la hora de requerir la demostración de aprendizaje por parte
de los estudiantes. “El enfoque de la evaluación y el assessment en línea es
asegurar que el aprendizaje ha ocurrido. Si el método utilizado es tal que obstruye
una evaluación efectiva del aprendizaje, enfoques diferentes necesitan ser
considerados” [SIEMENS, 03]
Adicionalmente, una gran cantidad de proveedores de e-Learning están comenzando a
incorporar un nuevo componente a sus soluciones, que no podría categorizarse
completamente dentro de alguno de los tres tipos de elementos mencionados: la
simulación. “El concepto detrás de la simulación basada en computador en el e-Learning
es simple, pero convincente: La práctica hace al maestro.” [DAVIES, 03]. La posibilidad
de incorporar simuladores como estrategia de enseñanza en las soluciones de
aprendizaje ha sido facilitada gracias la disponibilidad cada vez mayor tanto de hardware
(procesadores y tarjetas gráficas) y de software (herramientas de animación como
Macromedia Flash) al alcance de los proveedores de e-Learning, y no solamente de
industrias más ostentosas como la aviación o la militar en donde la simulación ha sido
parte importante del entrenamiento de los individuos.
Todos estos componentes mencionados no son en general elementos independientes
dentro de un ambiente de aprendizaje. Las consideraciones pedagógicas y pedagógicas
en el diseño de cada uno de estos, y de las relaciones entre los mismos, es vital para
lograr un todo coherente.
1.1.3. Evolución Tecnológica
Desde el punto de vista tecnológico, como se menciona en [BARRON, 02], “el e-Learning
es quizás una de las áreas más beneficiadas con los diferentes avances experimentados,
posibilitando la creación de nuevos productos y servicios, permitiéndole evolucionar desde
un modelo inicial basado en contenidos visualizados en computadoras hasta abarcar un
amplio rango de tecnologías para el trabajo colaborativo y la distribución y administración
de contenido, innovaciones que han mejorado las capacidades iniciales del e-Learning”.
MISC-03-1-8
12
Los avances en redes de computadoras y el advenimiento de Internet a principios de los
90s introdujeron un conjunto innovaciones tecnológicas que permitieron al e-Learning
expandirse de modelos de negocio iniciales, orientados al desarrollo de contenidos
personalizados, a un conjunto de productos y servicios, cuya evolución en el tiempo se
puede observar en la figura 1.
Uno de los avances principales fue el surgimiento de los Sistemas de Administración de
Aprendizaje (LMS, Learning Management Systems) que “permitieron satisfacer las
necesidades de enseñanza tradicionales de los salones de clases y la administración de
contenido e-Learning” [BARRON, 02].
Figura 1. Evolución Tecnológica del e-Learning
Fuente: [BARRON, 02]
Otro progreso importante mencionado en [BARRON, 02] fue el surgimiento de
herramientas colaborativas sincrónicas, que permitieron a estudiantes distantes entre si
compartir una misma “aula virtual” a través de Internet. Su bajo costo, frente a soluciones
MISC-03-1-8
13
de videoconferencia satelital, ha permitido la difusión de esta modalidad de aprendizaje.
Asimismo, surgieron un conjunto de herramientas para la creación de contenido en línea,
de trabajo colaborativo asíncrono (el estudiante puede consultar el material disponible
cuando lo desee) y sistemas de evaluación a estudiantes, que han permitido dar un valor
agregado al e-Learning.
En la figura 1 puede apreciarse como el concepto de los Learning Objects (Objetos de
Aprendizaje) constituye una de las últimas tendencias en el e-Learning, así como el
intercambio de estos objetos (para poder distribuir contenidos instruccionales). También,
han surgido los LCMS6, los cuales permiten la creación y administración de contenido
instruccional en la forma de objetos de aprendizaje y ofrecen una forma granular de
enseñanza que los usuarios pueden personalizar a través de los LMS dependiendo de la
audiencia o del estudiante.
Entre otras tecnologías que han encontrado aplicación en el área del e-Learning se
encuentran la difusión de contenido multimedia, los juegos, las herramientas de
simulación, las cuales han permitido el surgimiento de nuevos proveedores de soluciones
de e-Learning basados en un ambiente tecnológico determinado.
1.1.4. Los objetos de aprendizaje (Learning Objects)
Como se pudo observar en la figura 1, que muestra una visión sobre la evolución
tecnológica del e-Learning, dos de las tendencias existentes en la actualidad son los
objetos de aprendizaje (Learning Objects) y el intercambio de estos objetos (entre
diferentes sistemas LMS o LCMS).
El concepto en sí de los objetos de aprendizaje constituye un “enfoque en el cuál el
contenido (de un curso, por ejemplo) es dividido en elementos o pedazos más pequeños,
[por un lado con el fin de que] puedan ser reutilizados, creados y mantenidos de manera
independiente, [pero también para poder ser] separados y recopilados o unidos
nuevamente de muchas formas diferentes” [EDUWORKS, 03] .
MISC-03-1-8
14
Debido a que el contenido de aprendizaje debe ser desarrollado centrado en los
estudiantes (sabiendo quiénes son y llevando un seguimiento de sus actividades), este
generalmente es construido dentro de un ambiente LMS que se encarga de administrar
todo el proceso de aprendizaje de cada estudiante [EDUWORKS, 03]. En la práctica,
generalmente los responsables por la creación del contenido de una solución de e-
Learning y los de la administración de un LMS son dos personas u organizaciones
diferentes: una empresa X es productora de soluciones de e-Learning y le provee a otra
empresa Y su solución para que pueda ser administrada a través del LMS que esta última
posee. Por lo tanto, para los desarrolladores de soluciones de e-Learning, son
importantes los siguientes factores [EDUWORKS, 03]:
• Interoperabilidad: Es bastante deseable que su contenido pueda trabajar en
múltiples ambientes de aprendizaje. De lo contrario, tendría que realizar procesos
adaptativos de sus soluciones por cada cliente interesado en ellas.
• Reutilización: Poder usar el contenido ya desarrollado, que había sido utilizado
previamente en un contexto diferente.
Estas necesidades brindan las bases para el concepto de Objeto de Aprendizaje
Reutilizable (RLO: Reusable Learning Object), en el cuál “el contenido es dividido en
pedazos con las siguientes características:
• Cada pedazo está en completa capacidad de comunicarse con un sistema de
aprendizaje (LMS, por ejemplo). Para esto es necesario basarse en métodos
estándares, con el fin de hacer el proceso independiente a las características
propias de cada sistema.
• Independencia lógica y funcional entre pedazos.
6 Learning Content Management Systems: Sistemas de Administración de Contenido de Aprendizaje
MISC-03-1-8
15
• Dado que un curso puede estar formados por muchos pedazos, la forma cómo
cada usuario navega o recorre cada uno de estos en un orden en particular es
controlada por el sistema de aprendizaje
• Cada pedazo debe contar con una completa descripción que facilite al sistema
localizar el pedazo apropiado en un determinado contexto” [EDUWORKS, 03].
Los objetos de aprendizaje son independientes de la técnica de diseño instruccional que
se siga, lo cuál permite que este enfoque pueda ser utilizado en diferentes metodologías
pedagógicas de los desarrolladores de soluciones o contenido de e-Learning.
Por consiguiente, según [MORTIMER, 02], son tres los componentes de una arquitectura
de e-Learning basada en Learning Objects: Los objetos de aprendizaje en sí, los
metadatos que describen estos objetos y los sistemas de aprendizaje, tal como se
muestra en la siguiente figura.
Figura 2. Elementos interdependientes de una arquitectura de Learning Objects
Fuente: [MORTIMER, 02] Los metadatos constituyen la descripción completa de cada objeto de aprendizaje. En la
gráfica es claro el papel de cada sistema de aprendizaje como administrador de los
objetos y de sus descripciones con el fin de facilitar la localización de cada objeto cuando
sea necesario, así como llevar al usuario la experiencia de aprendizaje que este necesita.
Sistemas de Aprendizaje
(LMS)
Objetos de Aprendizaje
Metadatos
MISC-03-1-8
16
Dos aseveraciones importantes se pueden extraer del anterior gráfico: Tanto la necesidad
de estándares que permitan describir de manera uniforme los objetos de aprendizaje, los
cuales pueden ser desarrollados con herramientas heterogéneas y por organizaciones
distintas, como la necesidad de una especificación que permita la comunicación entre los
sistemas de aprendizaje y los objetos instruccionales (tanto para cargar un objeto en el
ambiente instruccional del sistema, cómo para hacer un seguimiento de las experiencias
de aprendizaje de los usuarios, por ejemplo).
Algunas aproximaciones se han hecho ya en el pasado con respecto a estos estándares
necesarios para los metadatos del contenido de e-Learning y el intercambio de los objetos
de aprendizaje. Los conjuntos de especificaciones AICC7 e IMS8 son una prueba de ello.
Con la misma motivación, la iniciativa ADL (Advanced Distributed Learning, Aprendizaje
Distribuido Avanzado) del Departamento de Defensa de los Estados Unidos, alimentado
de estas experiencias anteriores, produjo el Modelo de Referencia para Objetos de
Contenido Compartibles (SCORM, por las siglas en inglés de Shareable Content Object Reference Model), que definiendo un modelo de agregación de contenido y un ambiente
de ejecución, ha brindado las bases para la interoperabilidad entre objetos y sistemas de
aprendizaje, y la reutilización de estos objetos en diferentes ambientes.
1.1.5. Los ambientes LMS (Learning Management System)
Como lo describe [GREENBERG, 02], “un LMS es una solución estratégica de alto nivel
para la planeación, distribución y administración de todos los eventos de aprendizaje
dentro de una organización, incluyendo cursos en línea, aulas virtuales y guiados por
instructor…remplazando programas de aprendizaje aislados y fragmentados con un
medio sistemático de evaluar y mejorar los niveles de competencia y desempeño a través
de la organización…El objetivo de un LMS es administrar a los estudiantes, llevando un
seguimiento de su progreso y desempeño en todos los tipos de actividades
7 Aviation Industry CBT (Computer Based Training) Committee (http://www.aicc.org) 8 IMS Global Learning Consortium, Inc (http://www.imsglobal.org)
MISC-03-1-8
17
En [ADL, 01] se muestra un modelo generalizado de los componentes o servicios de un
LMS, descrito como un “conjunto de servicios que administran el envío y seguimiento de
contenido instruccional a un estudiante”. Este modelo es ilustrado en la figura 3.
Figura 3. Modelo Generalizado de un Sistema de Administración de Aprendizaje (o LMS) Fuente: [ADL, 01]
Entre las capacidades de un LMS, mencionadas en [GREENBERG, 02], se pueden
mencionar
• Soporte a aprendizaje mixto: Debido a que los individuos aprenden de diferentes
maneras, los LMS deben ofrecer un currículo que mezcle salones de clase y aulas
virtuales fácilmente
• Herramientas de administración: A los administradores se les debe permitir
gestionar el registro y perfiles de los usuarios, definir roles, asignar currículos,
tutores, administrar el contenido, entre otras actividades. Todas estas
características deben ser administrables utilizando interfaces gráficas amigables
• Integración del contenido: El LMS debe estar en capacidad de trabajar con
material de cursos desarrollados por diferentes proveedores de la industria.
Perfiles de Estudiantes
Administración de Cursos
Evaluaciones Assessments Navegación
Administración de Contenido
Seguimiento (Tracking)
Despliegue de Contenido
Repositorio Local de
Contenido
MISC-03-1-8
18
• Adherencia a estándares: Es importante el soporte de estándares como SCORM
con el fin de permitir la interoperabilidad con soluciones de e-Learning
desarrolladas con diferentes herramientas.
• Evaluación de capacidades: Es importante que existan herramientas que permitan
crear evaluaciones dentro de los mismos cursos, con el fin de conocer el nivel de
competencias y conocimientos adquiridos por los individuos.
1.2. LA INICIATIVA ADL Y EL MODELO DE REFERENCIA SCORM
En [ADL, 01] se brinda una descripción de la iniciativa ADL y una introducción al conjunto
de especificaciones de SCORM9. En esta sección se comentan algunos apartes de dicho
documento, con el fin de lograr una visión clara sobre la forma en que a través de dichas
especificaciones se posibilitan la descripción de objetos instruccionales a través de
metadatos y la interoperabilidad entre objetos y sistemas de aprendizaje.
En 1997, el Departamento de Defensa de los Estados Unidos creó la iniciativa ADL
(Advanced Distributed Learning) con el fin de desarrollar una estrategia para el uso del
aprendizaje y las tecnologías de información para la modernización de la educación y el
entrenamiento y para promover la cooperación entre el gobierno, la academia y los
negocios en el desarrollo de una estandarización el e-Learning.
Con ADL, se busca el desarrollo de un entorno técnico común para el aprendizaje basado
en computador o en la web, que fomente la creación de contenidos instruccionales
reutilizables como objetos de aprendizaje (Learning Objects). El enfoque es hacia el
diseño de objetos instruccionales compartibles y el desarrollo de una economía de objetos
de aprendizajes.
9 Shareable Content Object Referente Model
MISC-03-1-8
19
Con esa visión, la iniciativa ADL definió un conjunto de requerimientos de alto nivel para el
contenido de aprendizaje para apalancar las prácticas existentes y promover el uso del
aprendizaje basado en tecnologías [ADL, 01]:
• Accesibilidad: La capacidad de localizar y acceder elementos instruccionales en
alguna ubicación remota y distribuirlos a otras ubicaciones.
• Interoperabilidad: La capacidad de poder utilizar elementos instruccionales
desarrollados con un conjunto de herramientas y bajo una plataforma específica,
en otros ambientes bajo otras plataformas o que utilicen otras herramientas.
• Durabilidad: La capacidad de lograr una independencia a los cambios
tecnológicos, sin necesidad de rediseño o reconfiguración de los elementos
instruccionales.
• Capacidad de reutilización: Poder incorporar o utilizar un mismo componente
instruccional en múltiples aplicaciones o contextos.
Cómo lo menciona el documento The SCORM Overview [ADL, 01], estos requerimientos
pueden ser puestos también como:
• La capacidad de un LMS para cargar el contenido desarrollado con herramientas
de diferentes proveedores e intercambiar datos con ese contenido.
• La habilidad de que varios LMS de diferentes proveedores puedan administrar el
mismo contenido.
• La habilidad de que múltiples productos LMS puedan acceder a un repositorio
común de contenido y cargarlo en su ambiente.
Con estos requerimientos en mente, se creó un modelo de referencia para los objetos de
aprendizaje compartibles: SCORM.
MISC-03-1-8
20
SCORM (Shareable Content Object Reference Model), brevemente, es un modelo que
referencia un conjunto de especificaciones y recomendaciones técnicas interrelacionadas,
diseñadas para satisfacer los requerimientos de alto nivel de la iniciativa ADL
mencionados anteriormente.
En su esfuerzo, SCORM ha aplicado desarrollos tecnológicos de diferentes grupos, como:
• IMS Global Learning Consortium, Inc. (http://www.imsglobal.org)
• AICC: Aviation Industry CBT (Computer Based Training) Comitee
(http://www.aicc.org)
• ARIADNE: Alliance of Remote Instructional Authoring & Distribution Networks for
Europe (http://www.ariadne-eu.org); y,
• IEEE LTSC: Institute of Electrical and Electronics Engineers Learning Technology
Standards Comitee (http://ltsc.ieee.org)
A partir de las anteriores aproximaciones se ha creado un conjunto de recomendaciones
para lograr implementaciones consistentes en toda la industria. Cabe mencionar que
SCORM se enfoca a la interfaz entre el contenido y los LMS. La funcionalidad y
capacidades particulares de cada LMS no son tratadas dentro de las especificaciones de
SCORM.
Este conjunto de especificaciones de SCORM se encuentra dividido en dos: El Modelo de
Agregación de Contenido (Content Aggregation Model) y el Ambiente de Ejecución
(Run-Time Environment)
1.2.1. El Modelo de Agregación de Contenido
Como se describe también en [ADL, 01], el propósito del SCORM CAM (Content Aggregation Model) es proporcionar una forma común para construir contenido para el
aprendizaje a partir de diferentes fuentes localizables, reutilizables, compartibles e
interoperables. Adicionalmente, el CAM define cómo el contenido puede ser identificado y
descrito, agregado en un curso (o una parte de este) y movido entre sistemas como los
MISC-03-1-8
21
LMS o repositorios de objetos instruccionales; además, define los métodos técnicos para
lograr estos procesos. El modelo también incluye las especificaciones para agregar
contenido y la definición de metadatos que describan detalladamente este contenido.
Como se describe exhaustivamente en [ADL2, 01], el CAM está compuesto de:
• Modelo de Contenido: Define los componentes SCORM que son utilizados para
construir una experiencia de aprendizaje a partir de recursos instruccionales
reutilizables, así como la forma en que son agregados estos recursos de bajo nivel
para formar unidades de instrucción de alto nivel. Dentro de la nomenclatura del
Modelo de Contenido se identifican los siguientes tres componentes:
o Assets (Activos): Son representaciones electrónicas de medios, texto,
imágenes, sonido, páginas web, objetos y cualquier otro elemento que
pueda ser enviado a un cliente Web. Puede ser descrito con metadatos
para permitir búsquedas dentro de repositorios con el fin de facilitar su
reutilización.
Figura 4. Ejemplos de activos (assets)
o Shareable Content Object (Objetos de Contenido - o Instruccionales-
Compartibles): Es la colección de uno o más assets, donde uno de ellos
está en capacidad de ser cargado por un LMS y comunicarse con este (a
través del Ambiente de Ejecución de SCORM). Un SCO es el recurso de
aprendizaje con el menor nivel de granularidad al que se le puede hacer un
seguimiento a través de un LMS utilizando el ambiente de ejecución de
SCORM. Al igual que los assets, y con la misma finalidad, un SCO puede
Página HTML
Archivo Audio
Archivo XML
Imagen JPEG
Funciones JavaScript
Animación Flash
MISC-03-1-8
22
ser descrito con metadatos. Para que un SCO pueda ser reutilizado, se
recomienda que sea diseñado independiente de un contexto en particular y
que sea pensado para ser unidades “pequeñas” de aprendizaje (en donde
lo pequeño se mira de manera subjetiva).
o Content Aggregation (Agregación de Contenido): Es un “mapa” que
puede ser utilizado para agregar los recursos de aprendizaje en una unidad
cohesiva de instrucción (curso, capítulo, módulo, etc.). Define la estructura
del contenido que proporciona el mecanismo para definir la secuencia en
que los recursos de aprendizaje (SCOs y Assets) son mostrados al usuario
o estudiante. También pueden ser descritos con metadatos.
Figura 5. Agregación de Contenido en SCORM
Fuente: [ADL2, 01]
• Metadatos: Define los mecanismos para describir instancias específicas de los
componentes del Modelo de Contenido (Asset Metadata, SCO Metadata y
Content Aggregation Metadata) de acuerdo con las recomendaciones para
metadatos de objetos de aprendizaje definidas por la IEEE LTSC10. Sus principales
componentes son:
10 Institute of Electrical and Electronics Engineers Learning Technology Standards Comitee (http://ltsc.ieee.org)
MISC-03-1-8
23
o Modelo de Información: Define el conjunto de elementos para describir
metadatos. Es esencialmente el diccionario de etiquetas para metadatos
que define el uso apropiado para cada elemento. El modelo de información
de metadatos de SCORM está dividido en nueve categorías [ADL2, 01]:
General: Información general que describe el recurso como un todo.
Ciclo de Vida (Lifecycle): Características relacionadas con la
historia y el estado actual del recurso
Meta-Metadatos: Información sobre los mismos registros de
metadatos
Técnica: Requerimientos y características técnicas del recurso.
Educativa: Características educativas y pedagógicas del recurso.
Derechos: Derechos de propiedad intelectual y condiciones de uso.
Relaciones: Define relaciones entre el recurso descrito y otros
recursos.
Anotaciones: Comentarios sobre el uso educativo del recurso
Clasificación: Ubicación del recurso dentro de algún sistema de
clasificación
o Representación XML (XML Binding): Define como representar en XML los
elementos del diccionario definido en el Modelo de Información.
o Perfiles de Aplicación (Application Profiles): Proporciona una guía de
cómo implementar metadatos en un ambiente SCORM: qué elementos del
modelo de información son obligatorios y cómo deben ser codificados para
ser compatibles con SCORM.
La siguiente figura muestra un fragmento de un documento XML que constituye los
metadatos de un SCO. En él se pueden identificar algunos de los elementos
pertenecientes al modelo de información de los metadatos de SCORM.
MISC-03-1-8
24
?xml version="1.0"?> <lom xmlns="http://www.imsglobal.org/xsd/imsmd_rootv1p2p1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.imsglobal.org/xsd/imsmd_rootv1p2p1 imsmd_rootv1p2p1.xsd"> <general> <title> <langstring>Inland Maritime Navigation Signals</langstring> </title> <catalogentry> <catalog>ADL Sample Courses Catalog</catalog> <entry> <langstring>1000-01-06</langstring> </entry> </catalogentry> <language>en</language> <description> <langstring>Sound and Light Signals</langstring> </description> <keyword> <langstring>Signals</langstring> </keyword> <keyword> <langstring>Audiable Indications</langstring> </keyword> <keyword> <langstring>Visual Indications</langstring> </keyword> <aggregationlevel> <source> <langstring xml:lang="x-none">LOMv1.0</langstring> </source> <value> <langstring xml:lang="x-none">1</langstring> </value> </aggregationlevel> </general> <lifecycle> <version> <langstring>1.1</langstring> </version> <status> <source> <langstring xml:lang="x-none">LOMv1.0</langstring> </source> <value> <langstring xml:lang="x-none">Final</langstring> </value> </status> <contribute> <role> <source> <langstring xml:lang="x-none">LOMv1.0</langstring> </source> <value> <langstring xml:lang="x-none">Author</langstring> </value> </role> <centity>
Título del Recurso
Categoría General
Palabras Claves
Versión del Recurso
Descripción del Recurso
Estado de Desarrollo(puede ser, por ejemplo,
Borrador –Draft- )
Categoría Ciclo de
Vida
MISC-03-1-8
25
<vcard>BEGIN:vCard ORG:ADL Co-Lab END:vCard</vcard> </centity> <date> <datetime>2000-01-27</datetime> </date> </contribute> </lifecycle> <metametadata> <metadatascheme>ADL SCORM 1.2</metadatascheme> </metametadata> <technical> <format>text/html</format> <size>13671</size> <location>Course01/Lesson01/sco06.htm</location> <requirement> <type> <source> <langstring xml:lang="x-none">LOMv1.0</langstring> </source> <value> <langstring xml:lang="x-none">Browser</langstring> </value> </type> <name> <source> <langstring xml:lang="x-none">LOMv1.0</langstring> </source> <value> <langstring xml:lang="x-none">Microsoft Internet Explorer</langstring> </value> </name> <minimumversion>5.0</minimumversion> </requirement> </technical> <educational> <learningresourcetype> <source> <langstring xml:lang="x-none">LOMv1.0</langstring> </source> <value> <langstring xml:lang="x-none">Narrative Text</langstring> </value> </learningresourcetype> <typicallearningtime> <datetime>0000-00-00T00:14:00</datetime> </typicallearningtime> </educational> <rights> <cost> <source> <langstring xml:lang="x-none">LOMv1.0</langstring> </source> <value> <langstring xml:lang="x-none">no</langstring> </value>
Categoría Meta-Metadatos
Categoría Técnica
Categoría Educativa
Versión de SCORM de los metadatos utilizados
¿Tiene costo el recurso?
Formato del archivo del recurso
Requerimiento TécnicoTipo, Nombre, Versión Mínima
Tipo de Recurso Instruccional
Categoría Derechos
MISC-03-1-8
26
</cost> <copyrightandotherrestrictions> <source> <langstring xml:lang="x-none">LOMv1.0</langstring> </source> <value> <langstring xml:lang="x-none">no</langstring> </value> </copyrightandotherrestrictions> </rights> <classification> <purpose> <source> <langstring xml:lang="x-none">LOMv1.0</langstring> </source> <value> <langstring xml:lang="x-none">Educational Objective</langstring> </value> </purpose> <description> <langstring>This Sharable Content Object will give the student a basic understanding of inland maritime navigation signals.</langstring> </description> <keyword> <langstring>Inland Navigation</langstring> </keyword> </classification> </lom>
Figura 6. Metadatos XML de un SCO
• Empaquetamiento de Contenido (Content Packaging): Su propósito es
proporcionar una forma estándar para intercambiar recursos de aprendizaje
digitales entre diferentes sistemas o herramientas. Un paquete de contenido
también puede definir la estructura (u organización) y el comportamiento esperado
de un conjunto de recursos de aprendizaje. Las especificaciones de
empaquetamiento de contenido definen entre otras cosas:
o El manifiesto: un archivo que describe el paquete en sí, y contiene
metadatos sobre el paquete, una sección opcional de organización que
define la estructura del contenido, y una lista de referencias a los recursos
que conforman el paquete.
o Cómo crear un manifiesto XML de un paquete
¿Existen otras restricciones de uso?
Categoría Clasificación
Nombre del sistema de clasificación(en este ejemplo, de acuerdo con su objetivo instruccional)
MISC-03-1-8
27
o Recomendaciones para empaquetar el manifiesto, los metadatos y todos
los archivos físicos (recursos instruccionales) relacionados, en un archivo
de intercambio de paquete (Package Interchange File), por ejemplo un
archivo comprimido ZIP.
Figura 7. Diagrama conceptual de un paquete de contenido SCORM Fuente: [ADL2, 01]
MISC-03-1-8
28
La siguiente figura ilustra un ejemplo del manifiesto XML de un paquete de contenido
SCORM.
<?xml version="1.0"?> <manifest identifier="SingleCourseManifest" version="1.1" xmlns="http://www.imsproject.org/xsd/imscp_rootv1p1p2" xmlns:adlcp="http://www.adlnet.org/xsd/adlcp_rootv1p2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.imsproject.org/xsd/imscp_rootv1p1p2 imscp_rootv1p1p2.xsd http://www.imsglobal.org/xsd/imsmd_rootv1p2p1 imsmd_rootv1p2p1.xsd http://www.adlnet.org/xsd/adlcp_rootv1p2 adlcp_rootv1p2.xsd"> <metadata/> <organizations default="B0"> <organization identifier="B0"> <title>Maritime Navigation</title> <item identifier="B100" isvisible="true"> <title>Inland Rules of the Road (HTML Format)</title> <item identifier="S100001" identifierref="R_S100001" isvisible="true"> <title>References and Lesson Objective</title> </item> <item identifier="B110" isvisible="true"> <title>Steering & Sailing Rules</title> <item identifier="S110001" identifierref="R_S110001"> <title>Conduct of Vessels in any Condition of Visibility</title> <adlcp:prerequisites type="aicc_script"><![CDATA[S100001]]></adlcp:prerequisites> <adlcp:maxtimeallowed>0000:30:00.00</adlcp:maxtimeallowed> </item> <item identifier="S110002" identifierref="R_S110002"> <title>Conduct of Vessels in Sight of One Another</title> <adlcp:prerequisites type="aicc_script"><![CDATA[S110001]]></adlcp:prerequisites> </item> <item identifier="S110003" identifierref="R_S110003"> <title>Conduct of Vessels in Restricted Visibility</title> <adlcp:prerequisites type="aicc_script"><![CDATA[S110002]]></adlcp:prerequisites> </item> </item> <item identifier="S100002" identifierref="R_S100002" isvisible="true"> <title>Lights & Shapes</title> <adlcp:prerequisites type="aicc_script"><![CDATA[B110]]></adlcp:prerequisites> </item> ….. </item> <metadata> <schema>ADL SCORM</schema> <schemaversion>1.2</schemaversion> <adlcp:location>Course01.xml</adlcp:location> </metadata> </organization>
Sección OrganizacionesDefine, entre otros, el esquema de
navegación recomendado. Cada paso es identificado como un item (el cual hace
referencia al id de un recurso en el atributo identifierref)
Ubicación del archivo de metadatos para una organización determinada
Sección Metadatos(Opcional) Con el fin de brindar una
descripción de TODO el paquete, con la sintaxis de metadatos del modelo de
información de SCORM)
MISC-03-1-8
29
</organizations> <resources> <resource identifier="R_S100001" type="webcontent" adlcp:scormtype="sco" href="Course01/Lesson01/sco01.htm"> <metadata> <schema>ADL SCORM</schema> <schemaversion>1.2</schemaversion> <adlcp:location>Course01/Lesson01/sco01.xml</adlcp:location> </metadata> <file href="Course01/Lesson01/sco01.htm" /> <dependency identifierref="R_D1"/> </resource> <resource identifier="R_S110001" type="webcontent" adlcp:scormtype="sco" href="Course01/Lesson01/sco02.htm"> <metadata> <schema>ADL SCORM</schema> <schemaversion>1.2</schemaversion> <adlcp:location>Course01/Lesson01/sco02.xml</adlcp:location> </metadata> <file href="Course01/Lesson01/sco02.htm" /> <dependency identifierref="R_D1"/> </resource> <resource identifier="R_S110002" type="webcontent" adlcp:scormtype="sco" href="Course01/Lesson01/sco03.htm"> <metadata> <schema>ADL SCORM</schema> <schemaversion>1.2</schemaversion> <adlcp:location>Course01/Lesson01/sco03.xml</adlcp:location> </metadata> <file href="Course01/Lesson01/sco03.htm" /> <dependency identifierref="R_D1"/> </resource> <resource identifier="R_S110003" type="webcontent" adlcp:scormtype="sco" href="Course01/Lesson01/sco04.htm"> <metadata> <schema>ADL SCORM</schema> <schemaversion>1.2</schemaversion> <adlcp:location>Course01/Lesson01/sco04.xml</adlcp:location> </metadata> <file href="Course01/Lesson01/sco04.htm" /> <dependency identifierref="R_D1"/> </resource> … … </resources> </manifest>
Figura 8. Ejemplo de un manifiesto XML de un paquete de contenido SCORM
Sección Recursos Información sobre los recursos que
hacen parte de la solución
Identificador del Recurso
Archivo Inicial o Punto de Entrada del Recurso
Archivo(s) que componen el recurso
Dependencias con otros recursos
MISC-03-1-8
30
1.2.2. El Ambiente de Ejecución de SCORM
El propósito del SCORM RTE (SCORM Run-Time Environment) es “proporcionar un
mecanismo para la interoperabilidad entre contenidos instruccionales basados en SCOs y
los LMS” [ADL, 01].
Un requerimiento de SCORM es que el contenido de aprendizaje pueda ser interoperable
entre múltiples LMS independiente de las herramientas utilizadas para la creación de este.
Para que esto sea posible, debe existir una forma común de iniciar o cargar el contenido
en el ambiente del LMS, una forma común para que el contenido pueda comunicarse con
un LMS y un conjunto de elementos de datos predefinidos (vocabulario) que sea
intercambiado entre el LMS y el contenido durante su ejecución y que formen la base de
la comunicación. Estas tres necesidades están cubiertas por los tres componentes de la
especificación del SCORM RTE, descrita en [ADL3, 01]:
• Launch (Carga/Inicio): Define un mecanismo común para que los LMS puedan
cargar en su ambiente recursos de aprendizaje: establece procedimientos y
responsabilidades para el establecimiento de una comunicación entre el recurso y
el LMS.
• API (Application Programming Interface): Es el mecanismo de comunicación
para informar a un LMS el estado de un recurso instruccional (iniciado, finalizado,
errores) y es utilizado para obtener y establecer datos (resultados, límites de
tiempo, etc.) entre el LMS y el SCO.
• Modelo de Datos: Es un conjunto estándar de elementos de datos utilizados para
definir la información que va a ser comunicada. En pocas palabras, define el
vocabulario de elementos de datos que tanto el LMS como el SCO deben conocer.
Con el Modelo de Agregación de Contenido de SCORM, se proporcionan mecanismos
para que los desarrolladores de cursos o soluciones de e-Learning en general, puedan
describir con metadatos sus recursos de aprendizaje y tengan una manera estándar de
MISC-03-1-8
31
empaquetar estos recursos antes de ser distribuidos a varios sistemas de aprendizaje.
Con el Ambiente de Ejecución de SCORM se posibilita que los recursos instruccionales
puedan comunicarse con el LMS que administrará la experiencia de aprendizaje del
estudiante. Todo lo anterior sin importar las herramientas utilizadas para la creación de los
recursos de e-Learning (conocidas en inglés como Authoring Tools) ni el ambiente LMS
en que estas experiencias se lleven a cabo.
1.3. LOS SERVICIOS WEB 1.3.1. Antecedentes
El desarrollo de aplicaciones distribuidas ha sido un campo importante de investigación
durante la evolución de la computación, desde los mainframes hasta las estaciones de
trabajo y redes punto a punto actuales. Prueba de lo anterior han sido las iniciativas
alrededor de DCE11 en los años 80’s, CORBA12, RMI13, COM14 y DCOM15 en los años
90’s.
Con la llegada del nuevo milenio, el escenario estuvo listo para la llegada de una nueva
generación de computación distribuida (los servicios web) basada en las necesidades de
los sistemas de información y la experiencia, no siempre satisfactoria, obtenida por las
anteriores tecnologías. Los elementos importantes son:
• La posibilidad de desarrollar aplicaciones distribuidas alrededor del uso de
diferentes servicios genéricos.
• La posibilidad de interoperabilidad dentro y entre organizaciones sin importar la
plataforma.
• Conformidad con la infraestructura y estándares existentes en Internet.
• Sólido soporte por parte de los diferentes proveedores de herramientas de
desarrollo y de administración.
11 Distributed Computing Environment 12 Common Object Request Broker Arquitecture 13 Remote Method Invocation (Java) 14 Component Object Model (Microsoft)
MISC-03-1-8
32
• Posibilidad tanto del modelo de comunicación sencillo de Internet
(Request/Response) como de modelos más complejos que impliquen manejo de
transacciones o seguridad, entre otros, donde sean necesarios.
Los servicios web (o Web Services) surgen para satisfacer estas necesidades y su
importancia no radica en la invención de una nueva tecnología, o de un cambio radical de
paradigma, sino en la posibilidad de integrar alrededor de Internet todo el desarrollo
tecnológico de más de dos décadas.
“La creación del lenguaje de programación Java a mediados de los 90’s y los posteriores
estándares creados por Sun Microsystems, establecieron una plataforma común para los
desarrolladores de software y dio nacimiento a la tecnología de los servidores de
aplicación. Los servicios web representan el próximo paso lógico, creando un canal
importante que permite tomar la información de un universo complicado y reducirla en una
función apropiada de cada negocio” [LITWACK, 02]
Dentro de cualquier negocio tanto empleados como clientes y socios necesitan tener
acceso a ciertos datos específicos, y generalmente el desarrollo de los sistemas
existentes en el interior de la organización no se encuentra orientado a la satisfacción de
estos diferentes tipos de intereses. Debido a la corta vigencia de una determinada
tecnología de desarrollo, las empresas terminan funcionando con aplicaciones
heterogéneas para cumplir sus tareas. Los servicios web están orientados hacia la
interoperabilidad, y mediante el intercambio de documentos XML 16 permiten la
comunicación entre estos sistemas dispersos.
Bill Gates en su mensaje a los desarrolladores y profesionales de las tecnologías de
información de Junio 14 de 2001 mencionó las motivaciones detrás de los Web Services y
el rol de XML en esta tecnología [WEB SERVICES, 02]:
15 Distributed COM (Microsoft) 16 eXtensible Markup Language (http://www.w3.org/XML)
MISC-03-1-8
33
“Muchos de nosotros tenemos la visión de un mundo en línea en donde las
constelaciones de PCs17, servidores, dispositivos inteligentes y servicios basados
en Internet puedan colaborar sin inconvenientes. Los negocios estarán en
capacidad de compartir datos, integrar sus procesos y unir fuerzas para ofrecer
soluciones personalizadas a sus clientes. La información que alguien o un negocio
necesite estará disponible sin importar el lugar donde se encuentre, el dispositivo
de computación, la plataforma o la aplicación que se utilice.
…
Las aplicaciones independientes de hoy en día y los sitios Web crean islas de
funcionalidad y datos. Cualquiera tiene que navegar manualmente entre diferentes
sitios web, dispositivos, y aplicaciones, registrándose cada vez, y en raras
ocasiones con la posibilidad de transportar datos consigo mismo. Las tareas que
debieran ser simples, tales como organizar una reunión con los colegas de otras
compañías y automáticamente actualizar el calendario de cada asistente, son una
pesadilla en el mejor de los casos, e imposibles comúnmente. Esta ineficiencia es
una fuente importante de improductividad
…
En el corazón de la solución se encuentra XML, un estándar de la industria
administrado por el World Wide Web Consortium (W3C). Permite a los
desarrolladores describir los datos intercambiados entre computadoras,
dispositivos inteligentes, aplicaciones y sitios web. Gracias a que estos datos se
encuentran separados de algún formato o definiciones de estilo, puede ser
fácilmente organizado, programado, editado e intercambiado. Así como la web
revolucionó la forma en que los usuarios le hablan a las computadoras, XML
transformará la forma en que las aplicaciones hablan entre si”
Como resultado de los cambios en la forma en que los negocios y los usuarios utilizan la
web, la industria está convergiendo a un nuevo modelo de computación que permitirá una
forma estándar de desarrollar aplicaciones, la conexión de procesos y el intercambio de
información a través de la web. Los servicios web están diseñados para ser esta
metodología de integración basada en Internet. Gracias a este nuevo modelo y su amplio
17 Personal Computers
MISC-03-1-8
34
soporte a XML se garantiza la interoperabilidad y cooperación entre negocios en la
economía basada en Internet. Mientras que el enfoque de Internet fue en alguna ocasión
proveer un portal de información y capacidades transaccionales, ahora permitirá que los
individuos o los negocios tengan relaciones electrónicas con cualquiera, transformando la
complejidad en simplicidad a través de los servicios web.
1.3.2. ¿Qué son los servicios web?
Actualmente en Internet se pueden encontrar diferentes definiciones para el nuevo
modelo de los servicios web. Por ejemplo, “para IBM los servicios web son aplicaciones
modulares, auto-descritas, auto-contenidas que pueden ser combinadas con otros
servicios web para crear nuevos productos, procesos y cadenas de valor. Los servicios
web son aplicaciones de Internet que cumplen con una tarea específica, o conjunto de
tareas, que trabajan con otros servicios web en una forma interoperable para llevar a cabo
su parte de un proceso complejo o una transacción de negocio.” [RAJASEKHAURINI, 02]
Para Microsoft, “Un servicio web es una lógica de aplicación programable que puede ser
accedida utilizando protocolos de Internet. Los servicios web combinan los mejores
aspectos del desarrollo basado en componentes y la web. Como los componentes, los
servicios representan la funcionalidad de una caja negra que puede ser reutilizada sin
preocuparse de cómo es implementado el servicio. A diferencia de las tecnologías de
componentes, los servicios web no son accedidos a través de protocolos específicos de
modelos de objetos, tales como DCOM (Distributed Component Object Model), RMI
(Remote Method Invocation) de Java, o IIOP (Internet Inter-ORB Protocol) de CORBA.
Por el contrario, los servicios web son accedidos a través de protocolos web y formatos de
datos ubicuos, tales como HTTP y XML. Además, la interfaz de un servicio web está
definida estrictamente en términos de los mensajes que un Web Service acepta y genera.
Los consumidores de un servicio web pueden ser implementados en cualquier plataforma
y en cualquier lenguaje de programación, siempre y cuando puedan crear y consumir los
mensajes definidos en la interfaz del servicio” [MICROSOFT, 02]
MISC-03-1-8
35
Las dos definiciones anteriores describen muy bien el concepto de los servicios web, y de
la misma forma encontraremos otras aproximaciones de otros proveedores, con igual
grado de precisión al referirse a este nuevo modelo de programación en la web. Sin
embargo, una definición globalmente aceptada no ha sido acordada aún entre todos los
participantes, por lo que es conveniente describir los servicios web de acuerdo con sus
características más importantes:
• Son componentes de software modulares, auto-contenidos, auto-descritos,
encapsulados y reutilizables.
• Están basados en estándares: Utilizan XML como formato de representación de la
información, SOAP 18 como protocolo para la invocación de métodos y el
intercambio de mensajes independientemente de la plataforma; WSDL19 para la
descripción en detalle de los servicios ofrecidos (interfaces), y UDDI 20 como
mecanismo de registro o directorio. Además, pueden ser publicados, localizados y
accedidos utilizando protocolos existentes, como TCP/IP21 y HTTP22.
• Son agregables, en el sentido de que pueden ser combinados con otros servicios
con el fin de crear procesos de negocio innovadores.
• Sus interfaces están definidas en términos de los mensajes que cada servicio
acepta y genera.
• Brindan la posibilidad de acceder los datos en cualquier momento y en cualquier
lugar.
• Permiten la integración de procesos y datos en el interior de las organizaciones, y
lo más importante, entre diferentes organizaciones, sin importar la plataforma en
que se encuentren y el lenguaje de programación que utilicen en sus ambientes de
desarrollo.
Más que una revolución, los servicios web son el resultado de una evolución tecnológica y
han sido construidos sobre enfoques y motivaciones en los que se ha venido trabajando
por años. Este nuevo modelo trae a las organizaciones múltiples beneficios:
18 Simple Object Access Protocol 19 Web Services Description Language 20 Universal Description, Discovery and Integration 21 Transfer Control Protocol / Internet Protocol
MISC-03-1-8
36
• Independencia de la plataforma: Esto es una realidad gracias a que toda la
arquitectura de los servicios web está basada en estándares de Internet.
• Integración de Aplicaciones Empresariales de una manera más eficiente: en los
últimos años, esta integración sólo era posible a través de soluciones propietarias
y con un considerable costo. Además, se facilitará la integración de aplicaciones
B2B23.
• La reutilización de la funcionalidad permitirá el desarrollo de soluciones en un
menor tiempo.
• Permitirá a las organizaciones enfocarse en sus propias competencias, utilizando
servicios especializados de terceros cuando sea necesario.
• Libertad de seleccionar, dependiendo del enfoque de cada empresa, la mejor
plataforma tecnológica: Gracias a los mismos estándares de los servicios web,
esto no significará en ningún momento quedar aislado del resto de organizaciones.
• Simplicidad (comparados con otros modelos de desarrollo de aplicaciones
distribuidas como DCOM, RMI, EJB24 o CORBA)
• Pueden ser vistos como una forma de extender las aplicaciones a una mayor
audiencia y atraer nuevos negocios.
En general, “los servicios web tienen el potencial de transformar Internet, de un mundo de
información estática basada en presentación a uno programable basado en datos
dinámicos” [DELOITTE, 02]
1.3.3. Arquitectura de los servicios web
Como se menciona en [WEBCOLLAGE, 03], “a nivel arquitectónico, los servicios web
promueven una arquitectura orientada al servicio (SOA25) en tiempo real. Su arquitectura
22 HyperText Transfer Protocol 23 Business To Business 24 Enterprise Java Beans 25 SOA (Service-Oriented Architecture): Arquitectura conceptual para la implementación de aplicaciones distribuidas, dinámicas y débilmente acopladas. Es una forma de diseñar sistemas de software que provean servicios ya sea a aplicaciones de usuario final o a otros servicios a través
MISC-03-1-8
37
imita el concepto de servicio del mundo físico. Esto es, el servicio se define una vez, y
luego se proporciona a múltiples usuarios. En el mundo del software, los publicadores [o
proveedores] de un servicio web, empaquetan un proceso de negocio como un ‘servicio
web’ compartible una vez, y luego la exponen a diferentes suscriptores [o consumidores]
para ser utilizada en múltiples contextos”.
Un servicio puede verse como una determinada funcionalidad o comportamiento de un
componente de software que puede ser utilizada por cualquier aplicación o inclusive otros
servicios, basado simplemente en un contrato expuesto a través de una interfaz.
En una arquitectura orientada al servicio se identifican las siguientes características
[STEVENS, 03]:
• El uso está basado exclusivamente en una interfaz publicada: Una interfaz
publicada es aquella que se encuentra expuesta en una red, que puede ser
utilizada por aplicaciones clientes heterogéneas (con características
desconocidas) y que por lo tanto su definición no puede ser cambiada tan
fácilmente como las interfaces públicas (que son generalmente utilizadas por
aplicaciones en un mismo sistema).
• La interfaz debe poder ser invocada a través de la red: Además de un cliente local,
un cliente en la red debe estar en capacidad de invocar el servicio expuesto por la
interfaz.
• La interoperabilidad es de vital importancia: Las interfaces expuestas deben poder
ser invocadas utilizando formatos de mensajes y protocolos de red que puedan ser
soportados por todos los clientes potenciales.
• Localización Dinámica: Un servicio debe poder ser localizado y utilizado de
manera dinámica (contrario a invocarlo de manera estática en el código de las
aplicaciones clientes). Esto implica la existencia de un tercero que pueda ser
utilizado para realizar búsquedas sobre los servicios necesitados.
de interfaces publicadas y localizables. Las arquitecturas orientadas al servicio no son una nueva noción, pero gracias a la aparición de los servicios web han tomado gran importancia.
MISC-03-1-8
38
De acuerdo con las anteriores características, se pueden identificar tres roles principales
en una arquitectura orientada al servicio: proveedores de servicios, consumidores de
servicios e intermediarios (brokers)
Figura 9. Arquitectura Orientada al Servicio
Fuente: [IBM, 03]
Estos tres roles conforman los elementos principales de la arquitectura de los servicios
web, y de acuerdo con [MICROSOFT2, 02] sus características son:
• El proveedor es el nodo de la red que expone la funcionalidad que va a ser
compartida por otras aplicaciones. El modelo de los servicios web está basado en
la posibilidad de utilizar en cualquier aplicación, sin demasiada complejidad, la
funcionalidad o lógica de negocio ya existente en otras organizaciones. Estas
cumplen su rol de proveedores al seleccionar qué funcionalidad de sus
aplicaciones van a compartir al mundo exterior a través de la web mediante un
servicio web. Una empresa dedicada a la meteorología, por ejemplo, podría
implementar una aplicación que brinde predicciones del estado del clima para una
determinada ubicación geográfica, y a su vez crear un servicio web que exponga
métodos u operaciones que permitan a otras organizaciones interesadas utilizar la
lógica desarrollada para la consulta climatológica.
• El consumidor es un nodo de la red que contiene cualquier aplicación cliente que
se puede comunicar utilizando el protocolo HTTP (navegadores de Internet,
INTERMEDIARIO
PROVEEDORSERVICIOS
CONSUMIDOR SERVICIOS
Publicar
Consumir
Buscar
MISC-03-1-8
39
aplicaciones de consola o de interfaz gráfica). Son estos consumidores o
aplicaciones cliente los que van a utilizar dentro de su lógica la funcionalidad
disponible en los servicios web de otras organizaciones, sin necesidad de volver a
reimplementarla. En el ejemplo anterior, una organización que necesite hacer
consultas del estado del clima (una empresa de aviación, por ejemplo) no estaría
en la necesidad de implementar toda la lógica compleja para determinar este tipo
de predicciones (no es su área de competencia tampoco). Simplemente tendría
que crear aplicaciones, que mediante estándares de Internet, puedan comunicarse
con los servicios web de las empresas dedicadas a la meteorología y utilizar la
funcionalidad expuesta a través de las interfaces de estos.
• El intermediario o broker es un nodo de la red que contiene un registro global de
los servicios web disponibles, similar a un directorio telefónico o una libreta de
direcciones. Es en este repositorio de enlaces o hipervínculos en el que los
consumidores harán búsquedas para encontrar el servicio web apropiado para la
aplicación que están desarrollando, y en el que los proveedores colocarán
(publicarán) información para que sus servicios web puedan ser ubicados.
Para poder garantizar la interacción o comunicación obligada entre los anteriores
participantes de la arquitectura de servicios web, era necesario acordar un conjunto de
estándares que garantizaran la interoperabilidad del nuevo modelo, sobre todo cuando los
diferentes roles pueden estar representados por aplicaciones o servicios implementados
con herramientas o sobre plataformas completamente heterogéneas.
1.3.4. Estándares de los servicios web
Básicamente son tres necesidades las que en principio necesitan ser soportadas por
estándares en la arquitectura de servicios web:
• Intercambio de datos y mensajes entre aplicaciones y servicios
• Descripción detallada de la funcionalidad de los servicios
• Registro público para la publicación y ubicación de servicios
MISC-03-1-8
40
Las anteriores necesidades son suplidas respectivamente por tres estándares de la
industria, basados en XML: SOAP, WSDL y UDDI.
Para hacer uso de la funcionalidad de un servicio web, un consumidor debe hacer
llamados a las operaciones soportadas, con los argumentos apropiados, utilizando el
protocolo que el proveedor soporte. Para este fin, debe haber un común acuerdo en el
mecanismo que se va a utilizar para el formato de los mensajes a intercambiar entre el
consumidor y el servicio web: invocaciones al servicio y las respuestas de estas
invocaciones. El protocolo de acceso simple a objetos SOAP (Simple Object Access Protocol) ha sido diseñado para permitir la invocación de funciones a través de HTTP y
mediante XML, garantizando el intercambio de mensajes requerido entre los servicios web
y los consumidores, independiente de la plataforma y el lenguaje de programación
utilizado.
A su vez, los consumidores necesitan una descripción detallada de la funcionalidad
expuesta en un servicio web, con el fin de que puedan interactuar apropiadamente con
este: nombre de las operaciones definidas, argumentos que espera, tipos de datos de
estos argumentos, tipos de datos de los valores de retorno de las operaciones, protocolos
soportados, entre otros. En otras palabras, un consumidor necesita una definición
completa de la interfaz de un servicio web, para poder formatear adecuadamente los
mensajes SOAP que enviará al servicio. Para este fin, se creó el lenguaje de descripción
de servicios web WSDL (Web Services Description Language), que a través de
documentos XML se permite a los proveedores proporcionar una descripción rigurosa de
la interfaz de sus servicios web.
SOAP y WSDL garantizan la interacción entre proveedores y consumidores en la
arquitectura de los servicios web. Sin embargo, para facilitar las interacciones, los
negocios necesitan una solución práctica para publicar la descripción de sus servicios,
con el fin de que estos sean ubicados y utilizados por diferentes consumidores
interesados. Un directorio o registro global de servicios web, cumpliendo el rol de
intermediario, interactúa tanto con los proveedores como con los consumidores para
proporcionar esta funcionalidad.
MISC-03-1-8
41
Los directorios especifican a los proveedores qué tipo de información es necesaria en la
publicación de servicios web (información de clasificación que permita categorizar los
diferentes servicios web disponibles, información de la ubicación física de estos en la
forma de URLs26, descripción textual de los servicios, entre otros).
Las principales interacciones entre el directorio y los consumidores son de carácter de
búsqueda. Los directorios facilitan la búsqueda dentro de su repositorio para permitir que
los consumidores puedan ubicar el servicio web apropiado y toda la información necesaria
que les permita utilizar su funcionalidad.
Esta funcionalidad del directorio global es posible mediante el almacenamiento de
registros UDDI. UDDI 27 es una especificación para registros de servicios web, que
contiene un conjunto público de implementaciones que permiten a los negocios registrar
información sobre los servicios que estos ofrecen con el fin de que otros negocios
(consumidores) puedan localizarlos.
Este conjunto de estándares dependientes de XML mencionados (SOAP, WSDL y UDDI)
brinda la infraestructura necesaria para una interacción real entre negocios a través de la
web mediante el uso de servicios web. Cada una de las especificaciones, no son
propietarias de un determinado proveedor, sino más bien un esfuerzo común de toda la
industria de la computación para brindar las bases necesarias para garantizar el
funcionamiento del nuevo modelo.
1.3.5. Los Servicios Web Interactivos
“Una de las promesas principales de los servicios web es permitir el ensamble de
aplicaciones web mediante el uso de componentes funcionales distribuidos sobre
múltiples ubicaciones. Sin embargo, el ensamble de aplicaciones web interactivas,
visuales con una apariencia cohesiva ha sido un reto.” [RESHEF, 02]
26 Uniform Resource Locator
MISC-03-1-8
42
La iniciativa original de los servicios web está enfocada en la reutilización de la lógica de
negocio implementada en algún lugar de Internet. Por lo tanto, la lógica de presentación o
interfaz de usuario de las aplicaciones que utilicen los servicios web debe ser creada o
implementada manualmente por los desarrolladores. Este escenario descrito es
denominado en [WEBCOLLAGE, 03] “Servicios Web Programáticos”.
“Los servicios web interactivos exponen la capa de interfaz de usuario de una aplicación.
Exponen aplicaciones web con múltiples pasos [en las cuales una interacción constante
por parte del usuario es necesaria para realizar una función determinada (y no un simple
llamado)] creadas utilizando un conjunto de tecnologías que incluyen un servidor web, un
servidor de aplicaciones y un sistema de almacenamiento. Los suscriptores de servicios
web interactivos pueden incorporar estos procesos de negocio interactivos en sus
aplicaciones web, presentando a sus usuarios aplicaciones integradas de proveedores
externos. Mientras que una aplicación web típicamente contiene múltiples páginas que
interactúan con el usuario final, la lógica de navegación y flujo de datos son escondidas
del suscriptor [al que se le presenta esta interacción de múltiples pasos, como la
invocación de una simple operación del servicio web]” [WEBCOLLAGE, 03]
WSIA28 y WSRP29 son dos estándares en progreso bajo la coordinación de dos grupos de
trabajo de OASIS 30 que buscan simplificar la creación de aplicaciones interactivas y
distribuidas mediante el uso de servicios web interactivos, orientados a la presentación y a
la interfaz de usuario. Ambos nacieron de los esfuerzos iniciados a mediados del 2001
cuando “en paralelo múltiples desarrolladores de portales reconocieron la necesidad de
solucionar el problema común…de cómo acoplar servicios interactivos remotos (llamados
‘portlets’) en un portal sin necesidad de implementar programación personalizada para
cada servicio remoto” [RESHEF, 03]. La siguiente figura ilustra la comparación entre los
servicios web programáticos (orientados a los datos) y los servicios web interactivos
(orientados a la presentación).
27 Universal Description, Discovery and Integration of Web Services. (http://www.uddi.org) 28 Web Services for Interactive Applications 29 Web Services for Remote Portlets 30 Organization for the Advancement of Structured Information Standards (http://www.oasis-open.org)
MISC-03-1-8
43
Figura 10. Servicios Web Orientados a la Presentación vs. Servicios Web Orientados a los
Datos Fuente: [RESHEF, 03]
En la figura anterior se ilustra como “al exponer lógica de negocio como interfaces XML,
los usuarios [de los servicios web] incurren en el esfuerzo de integrar la aplicación a sus
sitios,…lo cual es muy complejo para aplicaciones interactivas en las que el flujo de los
datos necesita varias páginas web debido a la necesidad de descomponer la aplicación
interactiva en funciones atómicas,…recomponer los llamados a la interfaz en un flujo de
datos y una presentación coherente,…actualizar las aplicaciones a medida que las
interfaces evolucionan para incorporar nueva funcionalidad…y por lo difícil de asegurarse
de que la calidad de la aplicación ensamblada cumple con los estándares de calidad del
proveedor” [RESHEF, 03] La estrategia de los servicios web interactivos se basa en “el
envío (a través de SOAP) de fragmentos de código HTML listos para utilizar, que el
XML HTML
Base de Datos
Capa de Negocio
Capa de Presentación
Base de Datos
Capa de Negocio
Capa de Presentación
Servicio Web ProgramáticoServicio Web Interactivo
MISC-03-1-8
44
usuario puede embeber en su sitio web sin necesidad adicional de procesamiento”
[RESHEF, 03]. WSIA y WSRP proporcionan los mecanismos para implementar esta
alternativa de servicios web orientados a la presentación.
Tomando el ejemplo ilustrado en [RESHEF, 03], una herramienta de selección de
productos en línea pudiera ser publicada como un servicio web interactivo. Tal
herramienta recibe un identificador de catálogo (“portátiles”, por ejemplo) y le muestra al
usuario todos los productos en el catálogo seleccionado. El usuario puede navegar entre
los productos desplegados en esta aplicación, ver los detalles de un producto y
configurarlo de acuerdo con sus necesidades. Una vez el producto es seleccionado y
configurado, el identificador del producto es retornado como respuesta del servicio web.
Gracias a la implementación de esta herramienta como un servicio web interactivo, una
aplicación web cliente lo único que necesita realizar es embeber el módulo web o portlet
en alguna de sus páginas31 , realizar una invocación al servicio web enviando como
argumento el tipo de de catálogo deseado (“portátiles” en este caso), y esperar el
identificador del producto seleccionado y configurado por el usuario, y luego tomar este
identificador para algún flujo de proceso de negocio específico de la aplicación. Los
detalles de presentación e interacción descritos en el párrafo anterior, son transparentes
para esta aplicación web consumidora del servicio.
En cambio, si este servicio de selección y configuración de productos fuera implementado
como un servicio web programático, la aplicación web cliente no solo necesitaría realizar
múltiples llamados al servicio (recuperar la lista de productos del catálogo, obtener los
detalles de un producto determinado, conocer las características que pueden ser
personalizadas de un producto, obtener el identificador de un producto seleccionado con
una configuración personalizada, entre otras) sino que también debe preocuparse por el
orden en que realiza estos llamados y la creación de la interfaz de usuario con las
características de navegación mencionadas en el ejemplo. Como puede deducirse, este
31 Los detalles de cómo se embebe un portlet de un servicio web interactivo en una aplicación web dependerán en gran parte de las herramientas que terceros desarrollen tanto para la creación como para el consumo de este tipo de servicios.
MISC-03-1-8
45
enfoque limitaría o dificultaría la integración del servicio de esta compañía en aplicaciones
web de sus socios de negocios.
Como se describe en [RESHEF, 03], WSIA y WSRP definen un conjunto de APIs que
permiten a los desarrolladores producir y consumir servicios web remotos interactivos,
cumpliendo los siguientes roles:
• Definen la noción de fragmentos de código de marcado válidos basados en
lenguajes de marcado existentes como HTML, XHTML, VoiceXML, etc.
• Proporcionan un conjunto de llamados estándares para permitir que un
consumidor solicite estos fragmentos de un proveedor de servicios web
interactivos.
• Proveen un conjunto de llamados que soportan el concepto de una interacción con
el usuario en múltiples pasos y la preservación del estado entre estos llamados.
Dada la amplitud y complejidad de estas especificaciones, se espera que los proveedores
se basen en herramientas de terceros para el desarrollo de servicios con WSIA y WSRP,
de la misma forma como se basan en este tipo de herramientas para el desarrollo de
servicios web sin entrar en los detalles de las especificaciones SOAP, WSDL o UDDI,
manteniendo de esta forma su enfoque en la implementación de la funcionalidad de sus
servicios.
Como se menciona también en [RESHEF, 03], “a pesar de que los estándares WSIA y
WSRP aún se encuentran en evolución32, diferentes proveedores ya están suministrando
diferentes soluciones prácticas, que se irán actualizando a medida que las
especificaciones maduren:
• Epicentric 33 y otros desarrolladores de portales se están concentrando en la
agregación de servicios web remotos en portales.
32 La primera versión de WSRP fue liberada como estándar en septiembre de 2003, y al momento de la elaboración de este documento, OASIS (http://www.oasis-open.org), el consorcio responsable de esta especificación, se encuentra trabajando en los detalles de las siguientes versiones. 33 http://www.epicentric.com
MISC-03-1-8
46
• IBM 34 y otros desarrolladores de servidores de aplicación J2EE están
desarrollando herramientas que posibiliten la creación de servicios web desde cero
con el poder de WSIA y WSRP.
• WebCollage35 y otros integradores de aplicaciones se están enfocando en ayudar
a las compañías a empaquetar sus aplicaciones web existentes de tal forma que
puedan ser utilizadas remotamente tanto por sus clientes como por sus socios de
negocio”. De hecho, WebCollage Syndicator es una solución de servicios web
interactivos, diseñada para soportar el proceso completo de compartir aplicaciones
web interactivas y procesos de negocio con sus socios y aliados.
34 http://www.ibm.com 35 http://www.webcollage.com
MISC-03-1-8
47
2. LOS SERVICIOS WEB DE E-LEARNING
2.1. MOTIVACION
Como pudo observarse en el marco teórico de este documento, la industria del e-Learning
ha hecho grandes esfuerzos en un proceso de estandarización alrededor de las
soluciones de aprendizaje, con el fin de que estas puedan ser descritas de una manera
uniforme y puedan ser utilizadas por los diferentes ambientes LMS. Fruto de esos
esfuerzos han sido la iniciativa de Aprendizaje Distribuido Avanzado ADL y el conjunto de
especificaciones que esta ha impulsado, agregadas en lo que hoy en día es SCORM.
SCORM ha sido diseñado para garantizar la interoperabilidad entre SCOs36 y sistemas
LMS, y proporcionar mecanismos estándares de distribución de estos objetos
instruccionales. De hecho, un SCO puede concebirse como la estandarización del
concepto de los Objetos de Aprendizaje Reutilizables (RLO37).
Resumiendo lo descrito en SCORM, el proceso completo de creación y distribución de
contenido instruccional (basado en SCOs) para llevar experiencias de aprendizaje a los
usuarios puede ser visto en la siguiente figura [EDUWORKS, 03]:
36 Shareable Content Object (Objeto de Contenido Compartible) 37 Reusable Learning Object
MISC-03-1-8
48
Figura 11. Proceso de creación y distribución de SCOs
Como puede observarse en la figura, el modelo de referencia SCORM ha logrado
establecer un conjunto de recomendaciones en la forma como los elementos de una
solución de e-Learning pueden ser descritos, agregados y “empaquetados”, para que
puedan ser enviados a diferentes LMS, con el fin de que estos administren las
experiencias de aprendizaje de sus usuarios.
Revisando detalladamente el documento The SCORM Overview ([ADL, 01]), uno puede
describir la visión de la iniciativa ADL como la posibilidad de obtener experiencias de
aprendizaje cuyos componentes sean ensamblados en tiempo real, bajo demanda,
independientemente del lugar y del momento en que se necesiten. Esta visión concuerda
con las necesidades de la arquitectura de servicios web que esta tesis busca describir,
mencionada en la introducción de este documento.
El logro de esa visión, sería muy importante para los desarrolladores de soluciones de e-
Learning, pues les permitiría ofrecer experiencias de aprendizaje adaptables a las
necesidades de los usuarios, y por ende motivaría la utilización de mecanismos más
flexibles de distribución que permitieran llevar los elementos de esas experiencias hasta el
lugar donde los individuos lo necesiten y en el momento en que sea necesario.
SCO
SCO
SCO
SCO
Cada SCO es creado independientemente
Content Package
Varios SCO’s son empaquetados (en un
archivo ZIP, por ejemplo) junto con sus metadatos. Cada paquete contiene
un manifiesto XML
Los paquetes son distribuidos (enviados) a diferentes LMS
(SCORM-Conformant,) quienes se encargan de
administrar el contenido de estos en sus ambientes
LMS
LMS
Los usuarios (utilizando su navegador de Internet)
obtienen experiencias de aprendizaje administradas
por el LMS
MISC-03-1-8
49
También, el logro de esa visión sería importante para todas las aplicaciones con
necesidades de e-Learning, además de los LMS, pues habilitaría un modelo en el que
puedan capturar el contexto de las necesidades de sus usuarios en determinado instante
y construir la experiencia instruccional adecuada.
Si bien es importante resaltar la uniformidad en la descripción de soluciones de e-
Learning que se ha logrado gracias a las recomendaciones de SCORM, también es
conveniente mencionar que el mecanismo de distribución existente (descrito en la figura
8) dista mucho de cumplir la visión ADL debido a la falta de flexibilidad en el
empaquetamiento y distribución de soluciones de e-Learning: los proveedores de estas
soluciones empaquetan una experiencia de aprendizaje de acuerdo con un contexto o
necesidad en particular; y la distribución del paquete se realiza a través de mecanismos
convencionales como el envío de un archivo adjunto en un mensaje de correo electrónico,
o a través de una descarga de una página web, por ejemplo. A pesar de que la detallada
descripción de los recursos de aprendizaje a través de un conjunto de metadatos permite
su reutilización en múltiples contextos, no existe el concepto de un paquete que se genere
automáticamente con los elementos instruccionales necesarios por un estudiante o una
organización en particular.
Otro punto importante que se puede mencionar del análisis hecho de SCORM en el marco
teórico, es su fuerte tendencia hacia el aprendizaje basado en la web a través de un LMS.
Si bien es cierto que los LMS han permitido la administración de las experiencias de
aprendizaje de los empleados de una organización, es importante que al plantear un
nuevo modelo de distribución flexible de soluciones de e-Learning, este permita brindar
instrucción a los individuos, independiente de la existencia o no de un LMS en su
organización. Los LMS deben verse simplemente, para los propósitos de esta tesis, como
un tipo de aplicación con necesidades de e-Learning que se beneficiaría del nuevo
modelo. Para estos, incluso, también existe la problemática de adaptar la experiencia de
aprendizaje de acuerdo con las necesidades de sus usuarios. Es cierto, que un LMS
puede presentar diferentes alternativas de e-Learning a sus usuarios, pero dentro de las
posibilidades de contenido que se encuentren cargadas en su repositorio interno. Si en
algún lugar de Internet, algún proveedor ha desarrollado una solución de e-Learning de
MISC-03-1-8
50
particular interés para alguno de los estudiantes de los LMS, este no podrá tener acceso a
los recursos de esta debido a que el paquete no ha sido enviado y cargado en el LMS.
Por otro lado, recogiendo también lo analizado en el marco teórico, los servicios web han
probado su eficiencia en la integración de aplicaciones heterogéneas en Internet, gracias
a los diferentes estándares sobre los cuales se ha construido su arquitectura, una
arquitectura orientada al servicio en la que las empresas implementan una determinada
lógica de negocio, para que pueda ser utilizada tantas veces como sea necesaria por
otras aplicaciones en Internet. Este concepto probado de reutilización sería muy útil para
los proveedores de e-Learning: desarrollar e implementar sus soluciones, y que estas
puedan ser reutilizadas, preferiblemente de múltiples formas posibles, por diferentes
sistemas a través de la web, integrando de esta forma los servicios de e-Learning a su
propia lógica de negocio de manera transparente para el usuario final de las aplicaciones.
Resumiendo todo lo mencionado en los párrafos anteriores, en el nuevo enfoque deseado
por esta tesis para el logro de una arquitectura que permita la creación de soluciones
innovadoras de e-Learning en la que los usuarios obtengan experiencias de aprendizaje
ubicuas, dinámicas, transparentes y adaptadas a sus necesidades, es importante:
• Aprovechar las recomendaciones del modelo de contenido de SCORM, que
permiten describir de una manera estándar cualquier solución de e-Learning, sin
importar la cantidad ni el tipo de recursos que la conformen, así como la
reutilización de los recursos en diferentes contextos.
• Diseñar una arquitectura basada en servicios web, con el fin de que se posibiliten
mecanismos más flexibles de distribución de las soluciones de e-Learning, así
como su integración a diferentes aplicaciones interesadas en estos servicios.
El objeto de las siguientes secciones de este capítulo será la descripción de las
características esta nueva arquitectura propuesta de servicios web de e-Learning.
MISC-03-1-8
51
2.2. DEL PAQUETE DE CONTENIDO SCORM AL SERVICIO WEB
¿Qué elementos actuales dificultan un real dinamismo en la forma en que las experiencias
de aprendizaje son construidas? Básicamente, la forma estática en que los paquetes son
ensamblados antes de ser distribuidos, y la no existencia de mecanismos de distribución
flexibles de las soluciones de e-Learning, que permitan, por ejemplo, integrar un proceso
de ensamblaje bajo demanda dentro de alguna aplicación destinada para tal fin.
Desde el punto de vista de SCORM, no importa que un paquete de contenido exista en
algún lugar de Internet, si una persona tiene una necesidad de aprendizaje que pueda ser
suplida por el contenido de ese paquete, no podrá satisfacerla hasta que de alguna forma
el archivo llegue a su organización, y sea cargado dentro de un LMS en el que esa
persona tenga un perfil de estudiante. Una posibilidad de aprendizaje en tiempo real al
instante en que surge la necesidad, bajo estas condiciones, no es posible.
Adicionalmente, si la necesidad de aprendizaje de esa persona puede ser satisfecha sólo
con una parte de ese paquete, o debe ser complementada con otra porción de una
solución de otro proveedor, no habrá otra alternativa diferente a obtener dos paquetes
SCORM completos.
¿Qué elementos adicionales serían necesarios para lograr un acercamiento a esa
arquitectura de e-Learning distribuido necesitada? La propuesta de esta tesis considera la
introducción de un modelo basado en servicios web como mecanismo de distribución de
las soluciones de e-Learning, reemplazando la distribución física de un paquete de
contenido de SCORM.
En este nuevo modelo propuesto, las soluciones no serían más distribuidas como
paquetes de contenido, sino a través de interfaces expuestas en un servicio web XML;
interfaces que permitan construir soluciones personalizadas bajo demanda y en tiempo
real, utilizando todos los recursos u objetos (SCOs) que hacen parte de la solución
original, o sólo un subconjunto de estos de acuerdo a como sea necesario por la
aplicación cliente o el estudiante.
MISC-03-1-8
52
Con un enfoque orientado a las soluciones de e-Learning vistas como servicios, que
puedan ser utilizados por una gran variedad aplicaciones, más que como un paquete
físico y destinado exclusivamente a un LMS, se puede dar una gran aproximación en la
idea de garantizar una instrucción bajo demanda y con independencia de lugar y de
tiempo.
La estrategia de los desarrolladores de soluciones de e-Learning evolucionaría de un
proceso de empaquetar un conjunto de objetos instruccionales para ser distribuidos
manualmente a diferentes LMS, a uno en el que a través de la implementación de un
servicio web puedan brindar interfaces que permitan el acceso a los recursos
instruccionales de la solución creada desde una gran variedad de aplicaciones, gracias al
conjunto de estándares que dan soporte a este nuevo modelo. Por ejemplo, en este
nuevo enfoque, los cursos dejan de ser paquetes físicos distribuibles y se convierten en
servicios invocables a través de Internet.
Figura 12. Evolución del paquete de contenido SCORM al Servicio Web
La nueva propuesta, como puede observarse en la figura 12, se construye sobre el estado
actual de estandarización del e-Learning, el cual ha permitido a través de SCORM que los
proveedores de soluciones de aprendizaje puedan describir uniformemente el contenido
de estas, su estructura y su organización. El paso siguiente, una vez los metadatos de
una solución estén construidos, sería la implementación de interfaces que interactúen con
SCO
SCO
SCO
SCO
Content Package
SCO
SCO
SCO
SCO
Distribución de soluciones de e-Learning como Paquetes de
Contenidos SCORM
Distribución de soluciones de e-Learning como Servicios Web
Servicio
Web
MISC-03-1-8
53
ellos y con los recursos que describen, para que puedan ser comunicados o transferidos a
una aplicación cualquiera que utilice o invoque estas interfaces y que manifieste su
interés por una solución, de e-Learning. Es importante por lo tanto garantizar la
interoperabilidad con estas aplicaciones clientes de los servicios de aprendizaje,
independientemente de la plataforma en la que estén desarrolladas. Afortunadamente, la
misma arquitectura de los servicios web está pensada para ello.
2.3. BENEFICIOS
La implementación de soluciones de e-Learning como servicios web abre las posibilidades
de nuevos modelos de negocio para sus proveedores:
• e-Learning bajo Demanda: en donde los recursos de aprendizaje sólo son
utilizados el tiempo que sea necesario, y en la cantidad necesaria (sólo se
utilizarían los recursos de una solución que se consideren pertinentes), y en los
escenarios en donde exista una remuneración por el uso de estos servicios, los
proveedores podrán cobrar de acuerdo con estas tasas de uso de los mismos.
• e-Learning por suscripción: Los proveedores podrán manejar esquemas de
licenciamiento de sus soluciones de una manera mucho más dinámica,
permitiéndoles cobrar una cuota diaria, mensual, anual, etc., de suscripción a sus
servicios de acuerdo con las necesidades de sus clientes.
• Soluciones de e-Learning globales. Tradicionalmente, los proveedores de
soluciones de e-Learning proporcionan sus servicios a un conjunto limitado de
clientes. Con los servicios web de e-Learning, se abre la posibilidad para que
cualquier aplicación en Internet esté en capacidad de hacer uso de la experiencia
de aprendizaje proporcionada. Para que esto sea posible, una aplicación debe
estar en capacidad de localizar y utilizar dinámicamente un determinado servicio
web (una solución de e-Learning en este caso). Para lograr esta funcionalidad, los
desarrolladores de soluciones de e-Learning deberán previamente registrar sus
MISC-03-1-8
54
servicios en algún directorio público de servicios web en Internet, que pueda ser
consultado por una aplicación cliente.
Figura 13. Soluciones globales de e-Learning
El éxito de este escenario, para servicios de e-Learning no gratuitos, depende en
gran parte del establecimiento de garantías de comercio electrónico sobre la
infraestructura de servicios web, de la misma forma como se ha ido estableciendo
en las aplicaciones web, las cuales no son muy claras en el momento.
• Soluciones de e-Learning en cualquier dispositivo: Considerando el hecho de
que los servicios web están basados en estándares de Internet, un nuevo
beneficio surge: la posibilidad de llevar la misma experiencia de aprendizaje a
diferentes tipos de dispositivos (PC, Portátil, PDA, Celular, etc.). Y además de
múltiples tipos de dispositivos clientes, las experiencias de aprendizaje también
podrán ser integradas en una amplia variedad de aplicaciones, donde los LMS son
sólo una alternativa que se tiene, y no la única opción. Aunque es preciso
Macroeconomía
Matemáticas I
Teoría de Sistemas
Universidad que expone sus cursos e-Learning como servicios web en Internet
SOAP
Publicación de servicios web en directorios
Búsqueda de algún curso de Teoría de Sistemas
Descripción de la interfaz
SOAP
Aprendizaje Bajo Demanda
SOAP
SOAP
MISC-03-1-8
55
mencionar que si bien la tecnología de los servicios web permite esta
independencia de plataforma, las soluciones también deben ser desarrolladas con
esta misma motivación (por ejemplo, una página web que requiera Javascript ya
limita la variedad de navegadores que pueda ser utilizado).
Una inquietud puede surgir a raíz de esta implementación de servicios web para las
soluciones de e-Learning: ¿Qué tan complicado puede ser transformar el concepto físico
del paquete de contenido SCORM y llevarlo al concepto de una interfaz publicada que
ofrece un conjunto de operaciones específicas? Afortunadamente, esta evolución en la
manera de acceder a los recursos de una solución de e-Learning no implica grandes
trastornos. Si en algo SCORM ha dado un gran paso, es en la forma como ha
estandarizado los mecanismos para describir con metadatos cada uno de los recursos de
una experiencia de aprendizaje, para describir la estructura de navegación entre recursos
recomendada para el usuario, y la manera como se agregan diferentes recursos para
conformar una misma solución. Y lo más importante aún, estos mecanismos ya están
basados en representaciones XML, el mismo formato en que se deben codificar las
respuestas de un servicio web. Por lo tanto, los elementos que antes se representaban
exclusivamente como documentos XML físicos en el interior de un paquete de contenido
SCORM, ahora podrán estar representados como respuestas de los métodos de la
interfaz publicada del servicio.
Las anteriores son las consideraciones generales de esta nueva arquitectura distribuida
de aprendizaje propuesta basada en servicios web. A continuación se describen los
detalles particulares de la misma.
2.4. CARACTERISTICAS DE UNA ARQUITECTURA DE SERVICIOS WEB DE E-LEARNING
Como se describió en el marco teórico, en una arquitectura orientada al servicio como la
propuesta, se pueden identificar tres roles principales: los proveedores de servicios, los
consumidores o clientes de esos servicios, y un intermediario que proporcione servicios
de directorio.
MISC-03-1-8
56
2.4.1. Los proveedores de soluciones de e-Learning como servicios Web
Dentro de este rol se clasifican todas aquellas organizaciones especializadas en el
desarrollo de soluciones de e-Learning, incluyendo a instituciones educativas como las
universidades.
¿Cuáles son sus requerimientos para ofrecer soluciones de e-Learning como servicios
web?
Como se mencionó anteriormente, esta propuesta se basa en la estandarización existente
alrededor del e-Learning. Por lo tanto, para un curso creado, por ejemplo, será necesario
generar en primera instancia todos los metadatos necesarios que lo describan
completamente (unidades, capítulos, lecciones, orden de estos elementos, palabras
claves, etc.) de acuerdo con las especificaciones de SCORM. ¿Cómo son almacenados
estos metadatos? Es decisión propia de cada proveedor: como documentos XML en
disco, o como registros en tablas de una base de datos, por ejemplo. Lo importante es
que el servicio web pueda construir los metadatos XML en tiempo de ejecución a partir de
esa información almacenada y pueda comunicarlos a las aplicaciones que los necesiten
para conocer el contenido de la solución. La primera alternativa, guardar los documentos
XML de los metadatos en disco, es la más sencilla pues proporciona al servicio el
documento completo tal como debe ser transmitido a una aplicación: sólo es necesario
leer un archivo y transferir esa información.
La segunda preocupación se encuentra alrededor de la funcionalidad exacta que deberá
ser expuesta a través del servicio Web: la interfaz misma del servicio. ¿Cuáles son las
operaciones que deberán estar disponibles?
A continuación se describe el conjunto de operaciones que harían parte del API de los
servicios web de e-Learning. En ella existirá, entre otras, un conjunto de operaciones
básicas que permitan replicar la funcionalidad ofrecida inicialmente por el paquete de
contenido SCORM:
MISC-03-1-8
57
• getTitle: Obtiene el título de la solución de e-Learning creada
• getDescription: Descripción de la solución de aprendizaje.
• getKeywords: Esta operación permite recuperar las palabras claves generales
asociadas con el contenido de la solución de aprendizaje. Estas palabras claves
son útiles para ser indexadas por terceros y permitir la ubicación dinámica de
servicios de e-Learning.
• getManifest:: Esta operación permite consultar el manifiesto SCORM de una
solución (servicio web) de e-Learning. Como se describió anteriormente, con este
documento XML, una aplicación puede conocer una descripción detallada del
conjunto de recursos instruccionales (SCOs y Assets) que hacen parte de la
solución y la organización de estos dentro de un esquema de navegación
recomendado, entre otros.
• getResources: Permite obtener un listado descriptivo de los recursos
instruccionales que hacen parte del servicio web con su identificador, nombre y
descripción.
• getResourceMetadata: Su objetivo es consultar los metadatos XML (de acuerdo
con el modelo de información de SCORM) de un recurso instruccional
perteneciente a la solución. Para que el servicio web conozca cuál de todos los
recursos pertenecientes a la solución es el que debe ser descrito, su identificador
debe ser pasado como argumento en la invocación de la operación. Este
identificador puede conocerse en el manifiesto de la solución (recuperado con la
operación getManifest) o en la lista descriptiva de recursos (brindada en el método
getResources).
• getFiles: Cuando una aplicación desea una experiencia instruccional, debe
interactuar con uno o varios de los recursos instruccionales del servicio de e-
Learning. Cada uno de estos recursos tiene asociado uno o más archivos
(imágenes, animaciones, páginas HTML, ejecutables, etc.) Esta operación permite
descargar todos los archivos asociados a un recurso instruccional en particular
(cuyo identificador debe ser pasado como parámetro), con el fin de que el
“paquete” (o una parte de este) pueda ser ensamblado bajo demanda, o
simplemente para que el usuario interactúe con el recurso instruccional de forma
desconectada o fuera de línea. Existen esfuerzos en la industria para permitir que
MISC-03-1-8
58
junto a un mensaje XML de SOAP se puedan enviar elementos binarios (similar al
envío de archivos adjuntos en un mensaje de correo electrónico). Estas iniciativas
son SOAP Attachment Feature, coordinada por el W3C38, y DIME (Direct Internet
Message Encapsulation), administrada por el IETF39.
Los manifiestos o metadatos XML de SCORM también permiten referencias a
objetos remotos y no solamente locales, con el fin de que las aplicaciones, si lo
desean, puedan hacer uso de recursos que se encuentran en el servidor del
proveedor de la solución, sin necesidad de ser descargados localmente. Es decir,
se posibilita un escenario de utilización de la solución de e-Learning en línea, y no
sólo off-line (la lograda al descargar localmente los recursos y sus metadatos).
Como puede observarse, este tipo de servicios (a través de las operaciones mostradas)
está orientado principalmente a la provisión de contenidos (expresados como recursos
instruccionales) que se encuentran descritos principalmente por elementos del modelo de
contenido de SCORM (CAM40). Es precisamente un conjunto de recursos instruccionales
lo que se encuentra guardado en un paquete de contenido de SCORM, mientras que los
componentes restantes de evaluación y colaboración, que permiten crear un ambiente de
aprendizaje coherente, son generalmente responsabilidades delegadas a los LMS.
Por lo tanto, debido a que el contenido no es suficiente en muchas propuestas
instruccionales y a que el enfoque de la arquitectura propuesta por esta tesis busca ser
independiente del uso o no de un LMS, un proveedor podría crear adicionalmente
servicios web de evaluación y/o colaboración con el fin de extender el servicio web de
aprendizaje más allá de la funcionalidad ofrecida hoy en día por el paquete de contenido
SCORM, y de esta forma proporcionar los elementos básicos con los que un tercero
pudiera construir un ambiente de aprendizaje ajustado a sus necesidades.
Sin embargo, los servicios web de evaluaciones y de colaboración tienen una
característica en particular, que los diferencia de los servicios web de contenido descritos:
38 World Wide Web Consortium (http://www.w3c.org) 39 Internet Engineering Task Force (http://www.ietf.org) 40 Content Aggregation Model
MISC-03-1-8
59
la interactividad requerida por el usuario en todo el proceso para realizar una tarea en
particular.
Por ejemplo, para el departamento de recursos humanos de una empresa, su interés en el
uso de un servicio web de evaluaciones es quizás la obtención únicamente del resultado
de dicha prueba para verificar si sus empleados requieren entrenamiento especializado o
no en el tema de la evaluación. Pero para obtener el resultado, el estudiante debe analizar
todas las preguntas, interactuar con los diferentes tipos de selección de la respuesta
adecuada, revisar nuevamente las preguntas contestadas en las que existan dudas, etc.,
y al final de esta interacción es que podrá conocerse el desempeño del estudiante en la
prueba. En otro escenario, para colocar un mensaje en un foro de discusión, el estudiante
debe revisar los temas de conversación ya creados, para decidir si continúa una
conversación con su mensaje a publicar o crea una nueva conversación. Desde el punto
de vista del servidor del foro, la única información que necesita es un identificador de una
conversación y el mensaje a publicar.
Por la interactividad implícita en ellos, exponer servicios de evaluaciones o colaboración
como servicios web programáticos u orientados a los datos requeriría de una semántica
compleja de interacción de las aplicaciones con los servicios, cuya implementación, así
como la creación de la interfaz de usuario, sería responsabilidad de los consumidores de
los servicios web. Por lo tanto, para este tipo de funcionalidad, es recomendable la
implementación de servicios web interactivos, sobre todo cuando las especificaciones
WSIA y WSRP alcancen el grado de madurez y penetración necesario, y penetren en el
mercado las herramientas que faciliten la creación e integración de este tipo de servicios.
En este escenario propuesto, los proveedores desarrollarían aplicaciones web de
evaluación y colaboración que desean compartir, y luego mediante el uso de herramientas
de terceros que faciliten el uso de WSIA y WSRP (como Syndicator de WebCollage41), las
habilitarían como servicios interactivos remotos o portlets.
41 http://www.webcollage.com
MISC-03-1-8
60
Si un proveedor de servicios web de e-Learning implementa un portlet de evaluaciones,
una organización podría acoplarlo a su aplicación web interna, podría realizar una
invocación al servicio (un llamado para tomar una evaluación en particular) y obtendría
como retorno el resultado de la evaluación, sin necesidad de crear código para la interfaz
de la evaluación ni para la administración de la interacción con el usuario, las cuales son
responsabilidad de WSIA y WSRP (y del proveedor de la evaluación).
Figura 14. Ejemplo del uso de un servicio web interativo de evaluaciones
Al concebir evaluaciones o herramientas colaborativas como servicios web, es importante
pensar en la interfaz de los mismos. Tal como se ha mencionado, la interacción es
transparente a la aplicación cliente, pero esta debe conocer que tipo de respuesta retorna
un servicio posterior a su invocación. Por ejemplo, para un servicio web interactivo de
evaluación, la respuesta podría ser simplemente el puntaje total obtenido, o el porcentaje
de aprobación de cada una de las diferentes habilidades evaluadas con el fin de calcular
un puntaje ponderado, entre otras. Si cada proveedor de e-Learning proporciona una
interfaz diferente en un servicio web interactivo de evaluación, el dinamismo en la
integración de estos servicios en aplicaciones clientes independientes del proveedor se
vería limitado. Esta debería ser una de las próximas motivaciones de la industria del e-
Learning: definir estándares para representar resultados de evaluación, o para describir
actividades colaborativas, hasta donde sea posible, de la misma forma como se ha
avanzado con SCORM en la estandarización de los metadatos descriptivos del contenido
de e-Learning.
Servicio Web
Interactivo de
Evaluación
Aplicación Web de Evaluación del Proveedor
Aplicación Web Cliente
MISC-03-1-8
61
Sobre los simuladores en el e-Learning, el cuarto posible componente de las soluciones
de aprendizaje mencionado en el marco teórico de este documento, estos pueden ser
proporcionados por un proveedor como servicio con cualquiera de las dos estrategias
analizadas:
• Como un objeto o recurso instruccional adicional, al que hay que crearle sus
metadatos XML de SCORM para que pueda ser distribuido a través de la interfaz
descrita. Esta es una aproximación útil para simuladores implementados en la
forma de archivos ejecutables o animaciones de flash independientes (stand-
alone), por ejemplo.
• Como un servicio web interactivo, útil sobre todo si se ha desarrollado previamente
el simulador como una aplicación web.
Finalmente, es importante mencionar que la interoperabilidad entre los servicios web
creados por un proveedor y cualquier aplicación consumidora en Internet, independiente
de la plataforma de implementación tanto de servicios como de aplicaciones, depende
mucho de las herramientas utilizadas para la generación del material de e-Learning y no
de los mismos servicios.
En el caso de los servicios web de e-Learning, al estar basados en estándares de la
Industria como HTTP, SOAP, WSDL y WSRP, se garantiza la comunicación entre
aplicaciones y servicios. Pero si el material de e-Learning desarrollado, sobre todo el
contenido y los simuladores, depende de una plataforma tecnológica en particular o de
herramientas de uso específicas, esta dependencia se va a trasladar también a la misma
experiencia de aprendizaje (es decir, si no se cumplen las restricciones tecnológicas, no
existirá posibilidad de utilizar los recursos creados). Esta limitante se puede apreciar
claramente con un ejemplo: Si uno de los objetos instruccionales que hacen parte de un
servicio web de e-Learning es un archivo ejecutable desarrollado en el sistema operativo
Windows, una aplicación consumidora desarrollada sobre la plataforma Linux podrá
solicitarlo y descargarlo (porque la interfaz del servicio si es interoperable), pero no podrá
ejecutar el archivo localmente y por lo tanto se impediría la experiencia de aprendizaje.
Estas restricciones técnicas deben ser especificadas por los proveedores en los
MISC-03-1-8
62
metadatos SCORM de cada recurso, con el fin de que las aplicaciones consumidoras solo
tengan acceso al material de e-Learning con el que realmente pueden interactuar.
2.4.2. Los intermediarios o servicios de directorio
Como ya se ha descrito, en una arquitectura orientada al servicio es necesario un
catálogo o directorio global, en que las aplicaciones puedan consultar quiénes son los
proveedores que ofrecen servicios web de e-Learning que satisfagan las necesidades de
aprendizaje de sus usuarios.
Es en este servicio de directorio en el que los proveedores deberán publicar información
sobre sus servicios Web, de tal forma que puedan ser encontrados de manera dinámica
por las aplicaciones de e-Learning.
Como la propuesta de este artículo está basada en el estándar de los servicios web, la
primera alternativa es utilizar los servidores o registros UDDI para guardar esta
información. Al fin y al cabo, desde el surgimiento de los servicios web, los nodos UDDI
nacieron como los proveedores de los servicios de directorio para estos: proporcionar los
medios para que las aplicaciones puedan localizar dinámicamente negocios y servicios
ofrecidos por esos negocios.
Es necesario entonces analizar la forma como trabaja UDDI para verificar si estos
repositorios son suficientes para el escenario particular de los servicios web de e-Learning
tratados en este documento. En [BELLWOOD, 2002] se describe brevemente cómo un
registro UDDI es poblado con datos y cómo los clientes descubren y utilizan esta
información. En la siguiente figura se ilustra este proceso.
MISC-03-1-8
63
Figura 15. ¿Cómo funciona UDDI?
Fuente: [BELLWOOD, 02] Como se muestra en la figura 15, la publicación de información útil comienza cuando las
compañías de software o cuerpos de estándares definen especificaciones relevantes a
una industria o negocio, las cuales son conocidas como modelos técnicos o tModel. Un
tModel, al cual se le asigna un identificador único, brinda una descripción del tipo de
interfaz que un servicio web expone o implementa. Para el escenario de los servicios web
de e-Learning descritos, el primer paso sería el común acuerdo de la interfaz que estos
servicios implementarían, y a este tipo de interfaz se le asignaría un tModel. A través de
estos tModels se puede conocer qué otros negocios brindan servicios web similares.
REGISTROS UDDI
Los negocios pueblan el registro con descripciones de los servicios que
proporcionan
UDDI asigna un identificador único universal (UUID) a cada tModel y a
cada registro de negocio y almacena dicho registro
1
2 3
Aplicaciones de negocio o motores de búsqueda consultan el registro para descubrir servicios de otras
compañías
Los negocios utilizan esta información para facilitar la
integración entre si sobre la web
4
5
Las compañías de software, cuerpos de estándares, y programadores
llenan el registro con descripciones de diferentes tModels (modelos
técnicos)
MISC-03-1-8
64
En el segundo paso ilustrado, las compañías registran descripciones de sus negocios y de
los servicios que estos ofrecen. A su vez estos servicios son relacionados con uno o más
tModels definidos en el registro. La forma como un registro administra todo este conjunto
de entidades (negocios y servicios) es a través de la asignación de identificadores
universales únicos (UUID: Universal Unique ID) como se ilustra en el tercer paso.
En el cuarto paso, las aplicaciones interesadas consultan el registro para descubrir
servicios de interés. El conocimiento del identificador asignado a un tModel es importante
para esta operación en la mayoría de los casos, pues permite consultar qué negocios
ofrecen un determinado tipo de servicio (tipo de interfaz). A su vez, otros negocios pueden
invocar estos servicios registrados, permitiendo una integración simple o dinámica como
se muestra en el quinto paso.
Sin embargo, UDDI también presenta deficiencias. Como se menciona en [TARQUINO,
03], “UDDI está diseñado como un registro, no como un repositorio. Muchos de los
atributos de un servicio [web] registrado [en UDDI] son solamente URLs que apuntan al
sitio web de la compañía que los implementa. Las características y documentación
adicional de los servicios se encuentran en las URL pero UDDI no proporciona
mecanismos para obtener información de ellas aparte de su localización. La búsqueda
sobre estos documentos adicionales se considera una búsqueda extendida”.
Por ejemplo, para un servicio web de e-Learning, en UDDI estaría la información del
negocio que lo proporciona, información técnica sobre el servicio (URL en que puede ser
accedido, tModel asignado, entre otros), pero no estarían presentes todos los metadatos
adicionales que describen completamente el servicio web (requerimientos técnicos,
objetivos instruccionales, metadatos de cada uno de sus recursos, nivel de enseñanza,
entre otros). Para obtener estos metadatos, es necesario interactuar con la interfaz del
servicio web, invocando una o varias de sus operaciones. Por lo tanto, se puede concluir
que con la información publicada en UDDI, se podría conocer qué negocios ofrecen
servicios web de e-Learning, pero no se puede obtener una información precisa de cuáles
de esos servicios se ajustan a las necesidades particulares de aprendizaje de una
aplicación o un estudiante.
MISC-03-1-8
65
Por lo tanto, como UDDI no brinda la información requerida en un directorio de servicios
de aprendizaje, una posible solución es la de contar con un repositorio o directorio
especializado en servicios web de e-Learning (completamente independiente de UDDI),
que brinde mayor eficiencia o efectividad para este tipo de aplicaciones que desean
buscar solución a las necesidades de aprendizaje de sus usuarios. En este sentido,
HEKATE 42 , que también tiene una visión de repositorios de objetos instruccionales
distribuidos mediante servicios web, ha estado trabajando en el 2003 en el proyecto “A Web Services Clearing House”, un directorio abierto de servicios web orientados al
aprendizaje y entrenamiento, no como reemplazo o competencia a los estándares
actuales sino como extensión a los mismos.
Otra posible solución es la descrita en [TARQUINO, 03], en donde se describe la
necesidad de “Servicios de Valor Agregado” para poder realizar búsquedas efectivas de
servicios web, que incluyan por ejemplo la posibilidad de encontrar servicios por palabras
claves. Motores de búsqueda sobre UDDI de este tipo pueden mejorar la calidad de
información recopilada sobre servicios web de e-Learning registrados. Este servicio de
valor agregado del motor de búsqueda estaría implementado como una capa adicional
que utiliza a UDDI como fuente de información. Su diseño es “similar al de los robots que
utilizan los motores de búsqueda como Google43 para descargar el contenido de Internet
que luego indexan”.
Para el escenario de servicios web de e-Learning, la idea del uso de un motor de
búsqueda sobre UDDI especializado en la indexación de metadatos SCORM con el fin de
permitir consultas más avanzadas relacionadas con las soluciones de aprendizaje
existentes, permitiría el descubrimiento de servicios de e-Learning que se ajusten con
mayor precisión a las necesidades de los usuarios. La siguiente figura ilustra el rol de un
servicio de valor agregado sobre UDDI (motor de búsqueda especializado) para facilitar la
ubicación dinámica de servicios web de e-Learning, extendiendo el modelo de utilización
de UDDI descrito anteriormente.
42 Higher Education Knowledge And Technology Exchange (http://www.hekate.org) 43 http://www.google.com
MISC-03-1-8
66
Figura 16. Uso de un motor de búsqueda sobre UDDI especializado para facilitar la ubicación de servicios web de e-Learning
Al igual que los registros UDDI, la interfaz de consultas proporcionada por el motor de
búsqueda debe ser implementada como un servicio web para permitir la ubicación
dinámica de servicios directamente desde las aplicaciones y mantener la arquitectura
original de los servicios web. El administrador del servicio de directorio podría desarrollar
adicionalmente una aplicación web para facilitar las búsquedas directas de los usuarios a
través de un navegador.
De la figura 16, debe entenderse la necesidad de un registro público de servicios web,
sobre el cual el motor de búsqueda ubicaría servicios de e-Learning y descargaría su
información para indexarla localmente, mas no una dependencia exclusiva sobre UDDI.
REGISTRO PUBLICO DE SERVICIOS (UDDI)
Los proveedores registran sus servicios web de e-Learning en un
nodo UDDI
1
2
3
Periódicamente, el motor de búsqueda consulta el registro UDDI, para conocer cuáles servicios web de e-Learning se encuentran publicados, interactúa con la interfaz de estos servicios de e-Learning encontrados, y descarga e indexa los metadatos y manifiestos SCORM de estos servicios
Servicios Web de e-Learning
Aplicaciones consultan el servicio del motor de búsqueda para descubrir servicios de e-Learning de interés
MOTOR DE BUSQUEDA ESPECIALIZADO
MISC-03-1-8
67
UDDI es la tecnología actual de directorio de servicios web en Internet, y por lo tanto es el
registro utilizado. Pero si en el futuro se evoluciona hacia otro tipo de registros públicos, el
concepto del motor de búsqueda como un valor agregado sobre ese tipo de registro sigue
teniendo validez (mientras ese registro no brinde toda la información descriptiva
necesaria).
Como se describirá en la sección 3.1.2., la interfaz propuesta para el servicio web del
directorio de servicios de e-Learning, consta de una sola operación (findServices) que se
encarga de consultar qué servicios web satisfacen un conjunto de palabras claves, las
cuales son pasadas como argumento en la invocación de la operación. Sin embargo, este
primer API sencillo propuesto podría especializarse con nuevas operaciones que tengan
en cuenta criterios adicionales definidos en el modelo de información de SCORM:
pertenencia a un catálogo de cursos específico, características y requerimientos técnicos,
características pedagógicas, condiciones de uso, entre otros. Para lo anterior, no bastaría
únicamente con actualizar el API del servicio web de directorio, sino también modificar el
proceso que se encarga de descargar e indexar los metadatos de los servicios web de e-
Learning, con el fin de que tenga en cuenta nuevos elementos de información (que la
interfaz de los servicios web de contenido ya proporciona) para que el índice local de
servicios tenga a su disposición todos los datos necesarios sobre los cuales se realizarían
las búsquedas.
También se puede considerar la posibilidad de administrar directorios privados de
servicios de e-Learning, dentro de una organización donde se encuentra la aplicación que
desea hacer uso de ellos. Esta alternativa también sería útil pues se podrían tener en el
repositorio privado una copia únicamente de aquellos registros del directorio público que
tienen información sobre servicios de e-Learning gratuitos o a los cuales la organización o
usuario se encuentra suscrito, con el fin de limitar el espacio de búsqueda y aumentar las
posibilidades de encontrar un servicio que puede ser utilizado inmediatamente.
Estas tres posibilidades: directorio abierto especializado, servicio de valor agregado y
directorio privado no deben ser vistas como alternativas totalmente excluyentes. Alguna
combinación de las mismas también podría brindar una solución a la necesidad de contar
MISC-03-1-8
68
con un repositorio central de información sobre servicios web de e-Learning publicados en
Internet.
2.4.3. Los consumidores de los servicios web de e-Learning
En este último rol se encuentran todas las aplicaciones que buscan satisfacer las
necesidades de aprendizaje de sus usuarios. ¿Qué características deberán ser tenidas en
cuenta en la implementación de estas aplicaciones?
El principal requerimiento de las aplicaciones es que sean Web-Services-Enabled: es
decir, estar en capacidad de manejar los detalles de comunicación a través de estándares
como SOAP al momento de invocar los servicios web y los servicios de directorio,
manipulen documentos WSDL para comprender completamente las interfaces expuestas,
así como WSRP si necesitan integrar y utilizar servicios web interactivos.
Afortunadamente, algunas plataformas de desarrollo existentes en el mercado ya ofrecen
herramientas que facilitan esta tarea.
El segundo requerimiento es que sean SCORM-Enabled, es decir, estén en capacidad de
trabajar con los metadatos XML (para “entender” las descripciones de los recursos
instruccionales de los servicios de e-Learning) y los paquetes de contenido de SCORM
(cuando sea necesario ensamblarlos bajo demanda)
Se pueden mencionar algunos ejemplos importantes de uso de servicios web de e-
Learning que pueden presentarse para estas aplicaciones:
• Búsqueda dinámica de contenido e-Learning: La funcionalidad básica de una
aplicación de este tipo consiste en la utilización dinámica de servicios web de e-
Learning de acuerdo con los requerimientos del individuo: esto es, una vez
capturada las necesidades del usuario a través de su interfaz gráfica (palabras
claves, temas, etc.), la aplicación deberá buscar en el directorio de servicios web
de e-Learning quiénes son los proveedores que proporcionan soluciones que
satisfagan esas necesidades, con el fin de presentarle al usuario un listado de los
recursos encontrados. En este paso, incluso se podrá tener un primer contacto con
MISC-03-1-8
69
los servicios web directamente, con el fin de poder mostrar al usuario una lista de
la estructura y descripción del contenido de cada uno de ellos.
¿Qué puede pasar en ese momento? Los detalles de interacción con los usuarios
serán específicos de cada desarrollador de este tipo de aplicaciones, pero con el
modelo propuesto, un usuario podrá seleccionar toda una solución de un solo
proveedor, o subconjuntos de soluciones de diferentes proveedores (dentro de la
misma necesidad de aprendizaje). La aplicación, interactuando con las interfaces
ya mencionadas de los servicios, estará en capacidad de ensamblar un paquete
SCORM basado en los recursos o elementos seleccionados de uno o varios
proveedores, y luego administrar la experiencia de aprendizaje de su usuario
(ayudándole a navegar a través de los elementos de la solución, por ejemplo).
¿Cómo ensamblaría la solución? Para recursos instruccionales que provengan de
un mismo servicio web de e-Learning, el manifiesto de la solución le brinda a la
aplicación una descripción de cual es la navegación recomendada para estos
recursos (y cuáles son prerrequisitos de otros, por ejemplo), lo que garantiza (si la
aplicación cumple con estas recomendaciones) una coherencia instruccional para
el individuo. Sin embargo, si los recursos provienen de diferentes proveedores o
servicios, en el momento no existe información alguna que los organice, puesto
que provienen seguramente de enfoques instruccionales diferentes. En este caso,
será el mismo individuo el que decida la forma de navegación deseada.
Como puede observarse, para este tipo de aplicaciones, es más susceptible el uso
de los servicios web de contenido en estas interacciones dinámicas, que el de los
servicios de evaluación o colaboración, debido a que para estos últimos son
generalmente necesarias tareas de coordinación entre contenido, evaluaciones y
actividades colaborativas para garantizar una experiencia de aprendizaje
coherente.
MISC-03-1-8
70
Figura 17. Búsqueda dinámica de contenido e-Learning
Para ilustrar un ejemplo de este escenario de uso de servicios web, imaginemos a
una persona que se encuentra a punto de abrir un CDT44 en una corporación
financiera. Esta va camino hacia la entidad, pero tiene un poco de dudas sobre los
conceptos de tasas nominales y efectivas que se manejan con frecuencia al abrir
ese tipo de títulos. Esa persona hace uso en esos momentos del PDA que le
acompaña y utilizando su aplicación cliente llena un breve formulario en el que
especifica el tema en el que necesita ayuda. Su aplicación a continuación le
muestra un listado de universidades que ofrecen cursos de e-Learning en
Finanzas, con una breve descripción de los mismos y un contenido general de
cada curso. La persona, luego de revisar esta información, selecciona una de las
entradas mostradas en el resultado (luego de asegurarse que esta contiene la
información necesitada), quizás elige específicamente un tema dentro de ese
curso, y la aplicación lo lleva a estudiar el tópico que seleccionó. Después de unos
minutos, ya puede sentarse con la asesora comercial con la seguridad de poder
negociar unas tasas razonables una vez ya recuerda los conceptos que antes eran
difusos. El curso de Finanzas utilizado no será más necesario por lo pronto para
esa persona. Una ubicación y utilización dinámica de servicios de e-Learning se ha
llevado a cabo.
APLICACION
Contenido e-Learning
Directorio de Servicios de e-Learning
Servicios Web de e-Learning de diferentes proveedores
MISC-03-1-8
71
Como se pudo observar en el escenario mostrado, con los servicios web de e-
Learning existe la posibilidad de llegar a una economía de objetos de aprendizaje,
más que una de cursos, ya que gracias a la descripción detallada existente en los
servicios de aprendizaje (a través de metadatos SCORM) y expuesta a través de
métodos de la interfaz de estos, una aplicación cliente puede optar por utilizar
simplemente uno o varios de los objetos instruccionales que hacen parte de la
solución y no el curso en su totalidad, y combinar objetos instruccionales de
diferentes proveedores si así lo considera necesario el estudiante.
Para este tipo de aplicaciones, es importante que se implemente en su lógica el
análisis del manifiesto SCORM con el que cuenta cada servicio, sobre todo el de la
sección Organizations de este. Esta sección, como puede recordarse, es la que
contiene una recomendación por parte del proveedor de la forma en que deberían
examinarse los recursos instruccionales del servicio. Esta funcionalidad es
importante para que al momento de utilizar varios objetos de aprendizaje del
servicio (o todos), estos se examinen en un orden adecuado, sobre todo si el
interés del proveedor era expresar que algunos son prerrequisitos de otros. Esto
es válido como recomendación en la forma en que se debería navegar entre
recursos provenientes de un mismo servicio. Para recursos provenientes de
diferentes servicios web de e-Learning, no existe ninguna información disponible
que brinde una recomendación de cómo debiera organizarse la navegación entre
estos, ni se prevee que pueda existir debido a la independencia entre proveedores
para la generación de sus recursos instruccionales. En estos casos, se podría
mantener la estructura de navegación recomendada entre los objetos
instruccionales de un mismo servicio, pero sería el usuario el que decidiría con que
recurso instruccional de cualquiera de los servicios inicia su experiencia de
aprendizaje.
¿Quiénes desarrollarían estas aplicaciones? Como puede observarse, la lógica de
negocio principal de estas aplicaciones requiere de habilidades con la
44 Certificado de Depósito a Término Fijo
MISC-03-1-8
72
manipulación de metadatos y manifiestos XML de SCORM: identificar recursos
que hacen parte de una solución, su descripción, su organización, el esquema de
navegación entre recursos recomendado, etc. La curva de aprendizaje para
dominar este conjunto de especificaciones puede ser bastante alta, sobre todo
para poder integrar recursos provenientes de diferentes proveedores en Internet.
Es por esta razón que quienes desarrollarían inicialmente este tipo de aplicaciones
serían los mismos proveedores de las soluciones de e-Learning, como un valor
agregado para sus usuarios así como una forma de promover la utilización de sus
servicios. De igual manera, pueden existir intermediarios que además del
desarrollo de estas aplicaciones, podrían suscribir acuerdos con los proveedores
de e-Learning, y crear portales que integren para los usuarios soluciones de
aprendizaje basadas en los recursos instruccionales de sus diferentes socios.
• Integración a Sistemas de Información Organizaciones: En este tipo de
aplicaciones, las soluciones de e-Learning están integradas a la lógica de negocio
de los sistemas de información de las organizaciones, permitiéndoles brindar a sus
usuarios una experiencia de aprendizaje natural de acuerdo con el contexto en
particular de estos en su interacción con la aplicación. Lo natural se refiere al
hecho de que el usuario no debe utilizar otras aplicaciones especializadas para
acceder a la solución de e-Learning, más que las mismas aplicaciones con las que
se desenvuelve en sus actividades diarias, las cuales, dependiendo del contexto
del usuario en determinado momento, y si es necesario, le proporcionan la
experiencia de aprendizaje ajustadas a sus necesidades en ese preciso instante.
Figura 18. Integración a Sistemas de Información Organizacionales
NEGOCIO
Servicio Web de e-Learning
DATOS
PRESENTACION
APLICACION
MISC-03-1-8
73
El uso de los servicios web de e-Learning por parte de este tipo de aplicaciones no
tiene el mismo dinamismo del escenario anterior en la búsqueda de recursos
instruccionales. Por el contrario, las organizaciones ubican en Internet un servicio
web de e-Learning, o quizás varios, que contengan elementos instruccionales de
interés, y luego acoplan estos servicios en el interior de sus aplicaciones. El
dinamismo se encontrará en la forma como la aplicación decide cuándo es
necesario enseñar y qué recursos son los apropiados en ese momento,
dependiendo del contexto del usuario durante el uso de la aplicación.
También se puede considerar la posibilidad de crear aplicaciones externas,
especializadas en capturar el contexto del usuario en otros sistemas y determinar
el momento en que la experiencia de aprendizaje es necesaria. Esto con el fin de
incorporar soluciones de e-Learning para aplicaciones de terceros o sistemas ya
implementados, situaciones en las cuales no es sencillo modificar su lógica de
negocio para incorporar el uso de servicios web.
Para la creación de este tipo de aplicaciones, es necesario que los desarrolladores
se familiaricen con la comprensión de metadatos SCORM, con el fin de que
puedan integrar servicios externos en sus propios sistemas, para la creación de
procesos de aprendizaje realmente interesantes. Por ejemplo, la misma
corporación financiera descrita en el escenario anterior podría desarrollar una
aplicación que consuma el mismo servicio web del curso de finanzas que su
cliente utilizó, integrar además otro servicio que proporciona el valor de la DTF del
mercado en un determinado instante, proporcionando un buen balance entre la
teoría y la práctica (información actualizada) creando así una aplicación dinámica
que le permite entrenar o capacitar a sus asesores comerciales.
Además, en este escenario de experiencias de e-Learning naturales, el uso de los
servicios web de evaluación y colaboración si constituye una posibilidad. Además
de ubicar ciertos recursos instruccionales de interés, un departamento de recursos
humanos, por ejemplo, podría coordinar evaluaciones y actividades colaborativas
integrándolas a sus propios sistemas de información con el fin de llevar un
seguimiento del aprendizaje de sus empleados, o utilizar servicios de evaluaciones
MISC-03-1-8
74
para realizar pruebas de conocimiento en procesos de admisión. Como ya se ha
analizado, para integrar estos servicios web interactivos a las aplicaciones no es
necesaria la implementación de la lógica de presentación de la información
recibida.
• Los ambientes LMS: Una especial consideración merecen las aplicaciones que
hoy en día están especializadas en la interacción con paquetes de contenido
SCORM, y para las que la posibilidad de ensamblaje de paquetes bajo demanda
puede ser de gran interés: los LMS, como Lotus LearningSpace 45 de IBM, o
WebCT46 de WebCT, Inc, entre otros.47
Los LMS serán uno de los escenarios en los que se podrá comenzar a utilizar
este nuevo modelo de distribución de soluciones de e-Learning mediante servicios
web, ya que esta propuesta presenta una mayor eficiencia al momento de obtener
el paquete que contenga la solución de aprendizaje requerida y una mayor
flexibilidad al poder ensamblar soluciones para su ambiente a partir de los
desarrollos de diferentes proveedores.
Sin embargo, los servicios implementados en el interior de un LMS administran un
contenido basado en un repositorio local, donde los recursos de una solución son
cargados a partir de un paquete de contenido SCORM físico. En ningún momento,
esos servicios están en capacidad (hoy en día) de interactuar directamente con
servicios web para administrar su repositorio de contenido local.
Por lo anterior, en una primera fase de implementación de consumo de servicios
web de e-Learning en ambientes en donde exista un LMS, será necesario
involucrar una aplicación auxiliar o intermedia, con las mismas características del
primer escenario descrito, que se encargue de las tareas de búsqueda en los
servicios de directorio y del ensamble de paquetes de contenido SCORM bajo
45 http://www.lotus.com/products/learnspace.nsf/wdocs/homepage 46 http://www.webct.com 47 En este momento, son pocos los LMS que soportan el estándar SCORM, pero la tendencia de la industria en este tipo de aplicaciones es la de brindar el soporte requerido.
MISC-03-1-8
75
demanda. Una vez estos paquetes hayan sido generados, podrán ser
administrados y cargados a su sistema por los LMS.
Figura 19. Necesidad de aplicaciones auxiliares para LMS, durante la fase de
introducción de los servicios de e-Learning
Mirando hacia el futuro, el comportamiento esperado por los proveedores de los
sistemas LMS, es que extiendan los servicios ofrecidos actualmente como
funcionalidad de los mismos, y que estén habilitados para “hablar” directamente
con servicios web, sin la necesidad de aplicaciones intermedias. Este ambiente
vislumbrado extendería las capacidades actuales logradas con SCORM y los LMS,
y posibilitaría que las soluciones de e-Learning fueran ensambladas en tiempo
real, bajo demanda, y de acuerdo con las necesidades particulares de los
estudiantes.
Figura 20. Escenario futuro de los LMS con funcionalidades para consumir
directamente servicios web y ensamblar soluciones personalizadas bajo demanda
LMS
Servicios de e-Learning de diferentes proveedores
Estudiante con necesidades particulares
de aprendizaje
APLICACION INTERMEDIA
Content Package
LMS Servicios de e-Learning de
diferentes proveedores
MISC-03-1-8
76
Las anteriores son las principales características de un enfoque de soluciones de
aprendizaje expuestas como servicios web. Esta nueva arquitectura distribuida de e-
Learning, además de ser una mejor aproximación a la visión expresada por la iniciativa
ADL, tiene el potencial de “mejorar la enseñanza, el aprendizaje y la investigación como
nunca antes en la historia de la educación.” [HEKATE, 03]. Adicionalmente, esta
arquitectura propuesta facilita la creación de soluciones novedosas de e-Learning, que
puedan enseñar lo que un individuo necesita, donde lo necesite y en el momento que lo
requiera y, además, con la posibilidad de integrar el aprendizaje a las aplicaciones
empresariales, permitiendo entrenar o capacitar a sus usuarios de una manera natural y
transparente.
MISC-03-1-8
77
3. DISEÑO E IMPLEMENTACION
3.1. DISEÑO DE LA SOLUCION
Habiendo analizado previamente las características de una arquitectura de servicios web
de e-Learning, a continuación se pretende describir el diseño de la misma.
En primera instancia, se describirá el diseño de los servicios web (contenido, evaluación
y/o colaboración) que los proveedores de e-Learning implementarían y expondrían en
Internet, para luego describir el diseño de una propuesta de un servicio de directorio de e-
Learning implementado como un servicio de valor agregado sobre UDDI. Las otras dos
posibilidades de directorios (directorio abierto especializado y directorios privados) no son
consideradas en este diseño, debido a que la primera está siendo estudiada por
consorcios especializados de la industria (como HEKATE48), a cuya información no se
pudo tener acceso, pero sobre el resultado de dichos esfuerzos se puede tener la certeza
que cumplirán con las necesidades de la industria; y la segunda posibilidad está basada
en servicios de UDDI privados, como los ofrecidos por Windows® Server 2003, que serían
administrados en el interior de las organizaciones.
3.1.1. Diseño de la arquitectura de los proveedores de e-Learning
En la figura 21 se ilustra el diseño lógico por capas de la arquitectura de los servicios de
e-Learning proporcionados por los diferentes proveedores. Como se puede observar, los
servicios de evaluación y colaboración pertenecen a la capa de presentación: estos
servicios se deberían implementar como aplicaciones web tradicionales, con lenguajes
como ASP, ASP .NET, PHP, JSP, etc. 49, además de su interfaz de usuario deseada, para
48 Higher Education Knowledge And Technology Exchange (http://www.hekate.org) 49 Estos son lenguajes tradicionalmente utilizados para el desarrollo de aplicaciones web en Internet.
MISC-03-1-8
78
luego ser expuestos como servicios web interactivos haciendo uso de herramientas
especializadas de terceros, como WebCollage Syndicator50.
En la capa de dominio de esta arquitectura, se encuentra definido el paquete Metadata,
cuya responsabilidad es el manejo de los metadatos SCORM con el cual los proveedores
de e-Learning describen sus soluciones de contenido y los recursos que las componen.
De este paquete dependen los servicios web de contenido implementados (paquete
ServicioWebContenido), ya que estos se alimentan de dichos metadatos para brindar la
descripción que las aplicaciones consumidoras necesitan.
50 http://www.webcollage.com
MISC-03-1-8
79
Figura 21. Arquitectura lógica por capas del Proveedor de e-Learning En la capa de servicios técnicos encontramos varios elementos:
• PersistenciaMetadatos: Por su sencillez y flexibilidad, la recomendación hecha por
este documento es el almacenamiento de los metadatos como archivos XML,
siguiendo las recomendaciones de SCORM. Sin embargo, los proveedores
podrían seleccionar algún otro mecanismo de almacenamiento (bases de datos,
MISC-03-1-8
80
por ejemplo) para estos metadatos, cuyo manejo sería responsabilidad de este
paquete.
• SOAP: Este paquete se encarga del intercambio de mensajes en la comunicación
entre aplicaciones consumidoras y los servicios de e-Learning, de acuerdo con el
estándar Simple Object Access Protocol.
• DIME: Este paquete permite en envío de archivos binarios como elementos
adjuntos a un mensaje SOAP, de acuerdo a la especificación Direct Internet Message Encapsulation. Esta funcionalidad es necesaria por las aplicaciones
consumidoras para solicitar uno o varios recursos que hagan parte de la solución
de contenido implementada.
• WSRP: Este paquete es el que permite exponer las interfaces WSRP (Web Services for Remote Portlets) para las aplicaciones web de evaluación y/o
colaboración implementadas con el fin de que estas sean consumidas como
servicios web Interactivos.
• WSDL: Los proveedores deben brindar una descripción pública de las interfaces
de sus servicios web de contenido, evaluación y colaboración con el fin de que
sean “entendibles” por cualquier aplicación consumidora en Internet, y para esto
deben crear documentos XML que cumplan con el estándar Web Services Description Language. La responsabilidad de este paquete es ayudar a los
proveedores en la creación de estos documentos.
La complejidad en la implementación de los paquetes SOAP, DIME, WSRP y WSDL
generalmente será delegada a herramientas de desarrollo de terceros, como Visual Studio
de Microsoft®, WebSphere de IBM®, Sun ONE Studio de Sun Microsystems®, entre
otras, que ocultan los detalles de estas especificaciones a los desarrolladores de los
servicios.
La figura 22 ilustra los paquetes del proveedor relacionados con la funcionalidad de los
servicios web de contenido, y en las figuras 23 y 24 se describen los diagramas de clases
de cada uno de estos paquetes.
MISC-03-1-8
81
Figura 22. Paquetes Metadata y ServicioWebContenido
Figura 23. Diagrama de clases del Paquete ServicioWebContenido
MISC-03-1-8
82
Figura 24. Diagrama de clases del Paquete Metadata 3.1.2. Diseño de la arquitectura del directorio de servicios de e-Learning
En la figura 25 se describe el diseño por capas de la arquitectura de los servicios de
directorio de soluciones de e-Learning, implementados como un servicio de valor
agregado sobre UDDI.
El paquete ServicioWebConsulta, en la capa de aplicación, es el que proporciona la
interfaz que permite la ubicación de servicios de e-Learning a partir de un conjunto de
palabras claves como criterio de búsqueda. Esta funcionalidad es implementada como un
servicio web para permitir la integración con otras aplicaciones en Internet y la búsqueda y
uso dinámico de servicios de e-Learning en determinado momento.
MISC-03-1-8
83
Figura 25. Arquitectura lógica por capas del Directorio de Servicios Web de e-Learning
En la capa de dominio se encuentran los paquetes que tienen la responsabilidad de
mantener actualizado el repositorio local de información sobre los servicios de e-Learning
publicados en UDDI sobre el cuál se realizarán las consultas:
• Indexacion: Su responsabilidad es la de indexar localmente información sobre
servicios web de e-Learning (título, descripción, palabras claves, proveedor, etc.),
con el fin de hacer más eficientes las búsquedas.
• Crawler: Su responsabilidad es la de explorar un nodo UDDI en Internet (el
administrado por Microsoft, o IBM, por ejemplo) con el fin de ubicar entre todos los
servicios publicados únicamente los servicios web de e-Learning, interactuar con
MISC-03-1-8
84
la interfaz de cada uno de estos servicios para consultar información de interés
(título, descripción, palabras claves, etc.) que luego será indexada.
• Registro: Su objetivo es el de servir como fachada de acceso a un nodo UDDI para
recuperar la información de todos los servicios web de e-Learning publicados.
Figura 26. Paquetes principales del directorio de servicios de e-Learning Entre los servicios técnicos de soporte a la funcionalidad de los anteriores paquetes se
encuentran:
• PersistenciaIndice: La responsabilidad de este paquete es la de administrar el
almacenamiento de la información indexada de los servicios web de e-Learning,
en una base de datos por ejemplo.
• UDDI: El “crawling” de servicios de e-Learning (ubicar todos los servicios
publicados e interactuar con la interfaz de estos servicios para obtener información
descriptiva), depende de la información publicada en un nodo de registros UDDI
existente en Internet. La responsabilidad de este paquete es la de facilitar la
interacción con las APIs UDDI que dichos nodos exponen. Si en un futuro se
decide utilizar otro tipo de registro como fuente de información para el “crawling”
MISC-03-1-8
85
de servicios de e-Learning, este paquete debe ser reemplazado por uno que
brinde facilidad en el acceso las APIs de dicho nodo.
• SOAP y WSDL: Al igual que en los proveedores, la responsabilidad de estos
paquetes es la de formatear adecuadamente los mensajes intercambiados en la
comunicación entre aplicaciones y servicios, y la de describir la interfaz del servicio
web de consulta del directorio, respectivamente.
Las figuras 27 a 30 ilustran con mayor detalle los diagrama de clases de cada uno de los
paquetes Registro, Indexacion, Crawler y ServicioWebConsulta.
Figura 27. Diagrama de clases del Paquete Registro
MISC-03-1-8
86
Figura 28. Diagrama de clases del Paquete Indexacion
Figura 29. Diagrama de clases del Paquete Crawler
MISC-03-1-8
87
Figura 30. Diagrama de clases del Paquete ServicioWebConsulta
Adicionalmente, la figura 31 ilustra el diagrama de secuencia en donde se ilustran las
interacciones necesarias entre objetos del sistema para consultar los metadatos (título,
descripción y palabras claves en este caso) de los servicios web de e-Learning publicados
en UDDI con el fin de indexar esta información localmente y facilitar las búsquedas
realizadas a través del servicio web de consulta del directorio. A este proceso se le ha
denominado crawling, en analogía a los procesos llamados crawlers o spiders que
utilizan los buscadores existentes en la web (como Google51 por ejemplo) encargados de
navegar por todas las páginas posibles existentes en servidores web de Internet, indexar
su contenido y posibilitar búsquedas eficientes por palabras sobre el contenido local
indexado.
Este proceso descrito en el diagrama de secuencia permite mejoras para consultar mayor
información en la interacción con los servicios web de contenido (además de título,
descripción y palabras claves), con el fin de administrar un índice enriquecido de
metadatos que permita diversos criterios de búsqueda (siendo necesario para ello
modificar también la interfaz IWSDirectorio del servicio web de consulta del directorio).
51 http://www.google.com
MISC-03-1-8
88
Figura 31. Diagrama de secuencia del "crawling" de servicios web de e-Learning
MISC-03-1-8
89
3.1.3. Diagrama de Deployment
Finalmente, en la figura 32 se ilustran los diferentes componentes físicos que interactúan
en una arquitectura de servicios web de e-Learning.
Figura 32. Diagrama de despliegue físico de los componentes participantes en la arquitectura de servicios web de e-Learning
En la anterior figura se ilustran los servicios web de e-Learning que un proveedor podría
implementar: servicios de contenido (que implementan la interfaz IWSELearning descrita
anteriormente) y los servicios de evaluación o colaboración, que como servicios web
interactivos implementan las interfaces de WSRP.
MISC-03-1-8
90
Del lado del directorio se observan sus tres componentes claves: el servicio web de
consulta (WSDirectorio), el índice local de servicios de e-Learning y el componente
CrawlerELearning que se encarga de mantener actualizado este índice de acuerdo con la
información publicada en UDDI. A esto último se debe la dependencia ilustrada entre el
nodo del directorio y algún nodo de registros UDDI.
Los desarrolladores de aplicaciones consumidoras de los anteriores servicios harían uso
de herramientas de desarrollo de terceros que faciliten la creación de componentes
intermediarios o proxy tanto para los servicios web de contenido, evaluación y
colaboración, como para los servicios de directorio, con el fin de facilitar la integración de
la funcionalidad de estos servicios en las capa de negocio y/o presentación de dichas
aplicaciones.
3.2. IMPLEMENTACION DE LOS SERVICIOS WEB DE E-LEARNING Con el fin de tener una aproximación más clara acerca de las características tecnológicas
del nuevo enfoque propuesto, y su incidencia en el tipo de aplicaciones de e-Learning que
se pueden desarrollar, se implementaron unos prototipos que permitieran brindar este
primer acercamiento deseado.
Sin embargo, si bien el nuevo enfoque propuesto es más de carácter tecnológico que
pedagógico, sería imposible desarrollar un prototipo de aplicación o solución de
aprendizaje basada en servicios web sin contar con elementos de un ambiente de e-
Learning específico. Para este fin, se utilizaron materiales proporcionados por
AprendaHaciendo52, una empresa colombiana enfocada al desarrollo de soluciones de e-
Learning bajo una propia propuesta metodológica y además interesada en aprovechar los
resultados de esta tesis para generar nuevas propuestas en la provisión de sus
contenidos.
52 Ver anexo 2
MISC-03-1-8
91
3.2.1. Ambiente de Desarrollo
Toda la conceptualización desarrollada alrededor de esta propuesta de servicios web de
e-Learning y el diseño de los mismos descritos hasta este punto de documento no tiene
alguna dependencia tecnológica sobre alguna plataforma en particular. De hecho, como
se analizó en el marco teórico, toda la evolución de los servicios web en Internet ha sido
favorecida gracias a la independencia tecnológica de plataformas entre proveedores y
consumidores, sin que esto afecte el uso de servicios web desde las aplicaciones.
Sin embargo, para la implementación de estos servicios descritos, fue necesario
seleccionar un ambiente tecnológico en particular y un conjunto específico de
herramientas, más por facilidad de acceso y experiencia de desarrollo que por otro criterio
en particular.
A continuación se enumeran las características tecnológicas del ambiente de desarrollo
seleccionado:
• Sistema Operativo: Microsoft Windows 2003 Server Enterprise Edition, con los
siguientes servicios habilitados:
o Servidor Web: Internet Information Server 6.0
o UDDI Services
• Ambiente de Desarrollo: Microsoft Visual Studio .NET 2003
• Lenguaje de Programación: C#
• Motor de Base de Datos: Microsoft SQL Server 2000
En cuanto a la generación de metadatos para el contenido e-Learning, se utilizó la sintaxis
XML definida en la versión 1.2 de SCORM.
Adicionalmente, se hizo uso de las siguientes herramientas
• WebCollage Syndicator: Herramienta que permite exponer una aplicación web
como un servicio web interactivo. Es importante mencionar en este punto, que al
momento de la elaboración de este documento no existen herramientas que
MISC-03-1-8
92
permitan crear servicios web interactivos con base en las interfaces de WSRP, en
las cuales se ha hecho énfasis en la propuesta realizada, debido a su muy reciente
aceptación como estándar de la industria (versión 1.0). Sin embargo,
WebCollage 53 es uno de los proveedores de la Industria que ha liderado la
iniciativa de este tipo de servicios, y con esta herramienta soporta el concepto de
“módulos web” que pueden ser integrados a través de HTTP a múltiples
aplicaciones web de una manera sencilla para el desarrollador de estas. Por lo
tanto este tipo de módulos web fue seleccionado como aproximación al concepto
de servicios web interactivos que se pretende ilustrar. La empresa WebCollage
permitió acceso a una copia de evaluación de su producto, la cual fue utilizada en
esta tesis.
• Microsoft UDDI SDK 2.0: Librerías de Microsoft que facilitan la interacción con las
interfaces (API) de cualquier nodo UDDI (versiones 1.0 o 2.0) en Internet
• Web Services Enhancements 1.0: Herramienta que ayuda a la creación de
servicios web en Visual Studio .NET con soporte a las últimas especificaciones de
la industria. En particular, fue necesario para facilitar la implementación de DIME en los servicios web de e-Learning.
3.2.2. Implementación de un servicio web de contenido
En Visual Studio .NET 2003 se creó la solución Proveedor (Proveedor.sln), que está
conformada por los proyectos Metadata (Metadata.csproj, una librería de clases) y
ServicioWebContenido (ServicioWebContenido.csproj, un servicio web ASP .NET).
Cada uno de estos proyectos es la implementación de los paquetes con el mismo nombre
mencionados en el diseño de la arquitectura de los proveedores de e-Learning.
En cuando a dificultades encontradas en la implementación de este servicio, la única
identificada estuvo relacionada con la posibilidad de transferir archivos binarios dentro de
un mensaje SOAP, tarea que era necesaria en la operación getFiles de la interfaz del
53 http://www.webcollage.com
MISC-03-1-8
93
servicio web. La librería Microsoft.Web.Services.dll de Microsoft, también conocida
como Web Services Enhancements (versión 1.0) fue utilizada para facilitar la
implementación de dicha característica en la interfaz del servicio web. La ventaja de este
componente, entre otras, es la posibilidad de crear de manera sencilla servicios web que
soporten DIME (Direct Internet Message Encapsulation), un estándar en evolución que
permite el envío de elementos binarios adjuntos a un mensaje XML de SOAP. Su limitante
es que la aplicación cliente o consumidora del servicio web también debe tener instalada
dicha librería (eliminando la independencia de plataforma por consiguiente). Para efectos
del prototipo que se piensa ilustrar en esta tesis, su elección fue considerada apropiada.
Tal como se describió en el documento, la funcionalidad de este servicio web está basada
en los metadatos y manifiesto SCORM que el proveedor de e-Learning debe crear para
cada uno los recursos instruccionales que serán expuestos a través de la interfaz del
servicio, y que deben ser almacenados en forma de documentos XML (que cumplan con
la sintaxis SCORM 1.2) en el mismo servidor (específicamente, en la misma carpeta del
servicio web). En este momento, no existen herramientas que hayan automatizado esta
tarea o guíen al proveedor en la creación de dichos archivos, por lo que deben ser
creados manualmente.
Por lo tanto, para cada una de las cápsulas seleccionadas del Curso Básico de Excel XP
de AprendaHaciendo, se generó un archivo XML con sus metadatos SCORM (los
archivos 1112xx.XML). Para el servicio web, se generó el manifiesto SCORM del
“paquete” de contenido que iba a ser expuesto a través de su interfaz (el archivo
imsmanifest.xml).
En cuanto a requerimientos de plataforma que debe cumplir un proveedor de e-Learning
para exponer un nuevo servicio web con las mismas características del prototipo, se
tienen son los siguientes:
• Servidor Windows con el Framework de .NET 1.1 (Windows 2003 Server lo trae
instalado) y el servicio de Internet Information Server (servidor web) instalado.
• Microsoft Web Services Enhancements 1.0 instalado en el servidor.
MISC-03-1-8
94
3.2.3. Implementación de un servicio web interactivo de evaluación
Como ya se mencionó anteriormente, la principal limitante para desarrollar servicios web
interactivos que soporten las interfaces WSRP, como se describió en la arquitectura, fue
la falta de herramientas de terceros que soportaran este tipo de implementaciones. Por lo
tanto, se utilizó la herramienta WebCollage Syndicator para ilustrar el concepto de este
tipo de servicios. Syndicator permite convertir de manera sencilla una aplicación web en
un módulo (web) que puede ser integrado a otras aplicaciones sin preocuparse por los
detalles de interacción implícitos en el servicio (módulo). La principal limitación de estos
módulos web de Syndicator, es que únicamente pueden ser integrados a aplicaciones
web, y no a cualquier tipo de aplicación (no se puede invocar directamente desde una
aplicación windows, o en un PDA, por ejemplo).
Por consiguiente, el primer paso para que un proveedor proporcione un servicio de
evaluación, es la creación de la correspondiente aplicación web que la soporte. Esta
aplicación de evaluación fue creada con base en cinco preguntas seleccionadas de la
Evaluación de Conocimientos Básicos de Excel de AprendaHaciendo.
A continuación, para el proveedor, una vez desarrollada su aplicación web de evaluación,
su siguiente paso es convertirla en un servicio web interactivo, que en el caso específico
de la herramienta utilizada (WebCollage Syndicator) significa convertir la aplicación de
evaluación desarrollada en un módulo web.
Aunque los detalles de manejo de la herramienta Syndicator están fuera del alcance de
este documento54, en el material de evaluación del producto que se adjunta digitalmente
se encuentra la documentación del mismo si se desea mayor información al respecto.
Dos parámetros fueron importantes al momento de crear el módulo web en Syndicator:
54 En el anexo 1 de este documento se presenta una introducción a sus características técnicas
MISC-03-1-8
95
• El punto de entrada de la aplicación: cuando una aplicación realizara una
invocación del servicio de evaluación, cual sería la primera página web que
Syndicator debería procesar en la interacción con el usuario. Este punto de
entrada por defecto fue la página default.aspx.
• El punto de salida: la aplicación web subyacente debe enviar un mensaje XML a
Syndicator para indicarle que el procesamiento de esta ha terminado, con el fin de
que Syndicator devuelva el control a la aplicación consumidora del servicio. El
punto de salida se refiere al identificador de ese mensaje, que adicionalmente
puede encapsular datos (la respuesta del servicio).
El mensaje fin-evaluacion es el punto de salida del servicio, el cual es generado
en la página fin.aspx. Este es un ejemplo del mensaje de salida generado: <wsml:exit ref="fin-evaluacion">
<data-items> <puntaje>75</puntaje> <puntajeMaximo>100.0</puntajeMaximo>
<urlEstudio>http://www.aprendahaciendo.com/…</urlEstudio> <recursos>idRecurso1; idRecurso2; idRecurso3</recursos>
<palabrasClaves>palabra1, palabra2, palabra3</palabrasClaves> </data-items> </wsml:exit>
Como puede observarse, la respuesta del servicio de evaluación implementado
está compuesta de cinco parámetros:
• Puntaje: Resultado de la evaluación
• PuntajeMáximo: Puntaje máximo de la evaluación, con el fin de tener una
comprensión porcentual del nivel de conocimientos del estudiante.
• UrlEstudio: El servicio de evaluación, en caso de puntajes inferiores al
100%, recomienda un servicio web de contenido en el que el estudiante
puede reforzar sus conocimientos.
• Recursos: Una lista, separada por ‘;’, de los identificadores de los recursos
que el estudiante debería consultar en el servicio web de contenido
recomendado.
MISC-03-1-8
96
• PalabrasClaves: Una lista de las palabras que describen los temas en los
cuales el estudiante necesita reforzar sus conocimientos. Esta lista de
palabras puede ser utilizada posteriormente como parámetro al invocar la
interfaz del directorio de e-Learning, con el fin de ubicar servicios que
proporcionen el aprendizaje adecuado (y así no estar obligado utilizar el
servicio de contenido del mismo proveedor recomendado en el parámetro
urlEstudio)
Este es un punto que merece una profundización por parte de la industria del e-
Learning: estandarizar las interfaces de los servicios de evaluación (y/o
colaboración) con el fin de permitir flexibilidad en el uso de evaluaciones de
diferentes proveedores desde las aplicaciones de e-Learning.
Simplificando lo descrito hasta el momento, la implementación del módulo web realizada a
través de Syndicator permite que una aplicación web cliente invoque el servicio, y obtenga
una respuesta al mismo (los cinco parámetros definidos). Los detalles de la interacción
con el usuario con cada pregunta a través de la evaluación, son transparentes para la
misma y son administrados absolutamente por Syndicator
3.2.4. Implementación de un Curso Dinámico de Excel basado en Servicios Web
AprendaHaciendo, dentro de su portafolio de productos de e-Learning cuenta con varios
cursos enfocados principalmente al aprendizaje de tecnologías de información. Entre
algunos de sus títulos se encuentran Curso Básico de Word, Curso Intermedio de Excel,
Curso Avanzado de Internet, etc. Sin embargo, a pesar de que el diseño instruccional de
estos cursos permite una flexibilidad en el aprendizaje por parte del estudiante, su
contenido es estático, es decir, el material que recibe cada individuo en cada curso es el
mismo.
Basado en este nuevo enfoque de soluciones de e-Learning basada en servicios web, en
colaboración con AprendaHaciendo y su material de cursos e-Learning se desarrolló un
prototipo de un Curso Dinámico, en el que el estudiante recibe únicamente aquellos
recursos instruccionales que son aptos de acuerdo con sus fortalezas y debilidades en un
MISC-03-1-8
97
tema en particular. Específicamente, el prototipo ejemplifica un Curso Dinámico de Excel,
en el que periódicamente cada estudiante pueda recibir las unidades de aprendizaje
personalizadas a sus necesidades de acuerdo con evaluaciones realizadas en momentos
específicos valorar sus conocimientos. Tanto los recursos instruccionales, como las
evaluaciones son proporcionadas a través de servicios web (los implementados
anteriormente).
La solución que proporciona este Curso dinámico de Excel está conformada por dos
componentes principales:
• Una aplicación web: Un conjunto de páginas web que invocan el servicio web de
evaluación y guardan los resultados de cada estudiante en una base de datos
XML. Estás páginas pueden ser integradas a la Intranet de la empresa que
adquiere el curso, con el fin de que la información de los estudiantes concuerde
con la información de los usuarios de la red, y permitir, por ejemplo, que el
departamento de recursos humanos supervise el progreso de cada uno de los
estudiantes.
Esta aplicación sirve de intermediario en la invocación al servicio web interactivo
de evaluaciones. Fue requerida su implementación debido a que los módulos web
de WebCollage Syndicator, por sus características técnicas de operación,
únicamente pueden ser invocados a través de HTTP desde aplicaciones web (una
aplicación Windows no podría invocarlo directamente, por lo tanto).
• Una aplicación windows: la cual se mantiene presente en la bandeja del sistema
en el escritorio del computador de cada individuo, con la lista de recursos
instruccionales recomendados para el estudio de dicho estudiante. Esta aplicación
conoce cuáles son los recursos personalizados para cada estudiante de la
empresa consultándolos de la anterior base de datos de resultados que se guarda
en el servidor web, y a medida que el usuario selecciona alguno de ellos para
estudiarlo, la aplicación interactúa con la interfaz del servicio web de estudio
(recuérdese el parámetro urlEstudio en la respuesta del servicio de evaluación)
MISC-03-1-8
98
para descargar localmente los archivos que conforman dicho recurso.
Naturalmente, este proceso descrito es transparente para el usuario final.
3.2.5. Implementación de un servicio de directorio de e-Learning
Durante el análisis realizado sobre la arquitectura de servicios web de e-Learning, una de
las posibilidades surgidas fue su implementación como un servicio de valor agregado
sobre un registro público de servicios web (en este caso UDDI). Si bien, el diseño e
implementación apropiados de este motor de búsqueda se encuentra fuera del alcance de
esta tesis55, se desarrolló un prototipo sencillo con el fin de brindar un acercamiento a las
características de este tipo de directorios.
La solución desarrollada en Visual Studio .NET (Directorio.sln), la cual consta de cuatro
proyectos:
• Registro: Este proyecto es una librería de clases que contiene la implementación
del paquete del mismo nombre analizado en el diseño de la arquitectura del
directorio de servicios de e-Learning. Básicamente, encapsula el acceso (lectura
únicamente) a un registro público de servicios web, que en este caso es UDDI.
Para facilitar la interacción con el API de UDDI del nodo o registro seleccionado,
se utilizó la versión 2.0 de la librería Microsoft.Uddi.dll, conocida también como
Microsoft UDDI SDK 2.0.
• Indexacion: Una librería de clases que contiene la implementación del paquete
del mismo nombre analizado en el diseño de la arquitectura del directorio de
servicios de e-Learning. En este caso, por simplicidad, el índice fue implementado
sobre una base de datos en SQL Server 2000. Esta base de datos almacena
información básica sobre los proveedores (Businesses), sus servicios de e-
Learning ofrecidos (Services) y palabras claves de dichos servicios (Keywords).
55 Este tema de motores de búsqueda sobre UDDI es tratado con mayor detalle y profundidad en la tesis “Motor de Búsqueda sobre UDDI” [TARQUINO, 03] desarrollada por Jaime Tarquino sobre el tema.
MISC-03-1-8
99
• Crawler: Una aplicación de consola (por línea de comandos del sistema operativo)
que se encarga de realizar el crawling de servicios de e-Learning: realizar una
búsqueda de servicios de e-Learning sobre algún registro UDDI, e interactuar con
las interfaces de dichos servicios para descargar o almacenar en el índice local su
información básica (título, descripción, palabras claves, proveedor, etc.), con el fin
de hacer más eficiente las consultas realizadas posteriormente (sobre el índice
local).
Para que el anterior proceso funcione adecuadamente, son necesarios dos
elementos de información: ¿Cuál es el registro UDDI que se va a consultar?, y
entre todos los servicios web publicados en dicho registro, ¿Cómo se diferencia un
servicio web de e-Learning de uno que no lo sea?. Estos dos parámetros pueden
ser configurados en el archivo Crawler.exe.config:
• La variable UDDINodeInquireUrl contiene la URL de la interfaz de consulta
del nodo UDDI que se piensa consultar.
• La variable ELearningTModel contiene el valor del tModel que identifica de
manera única a la interfaz de los servicios web de e-Learning en UDDI.
Para realizar las pruebas de esta aplicación, se utilizó un componente adicional de
Windows 2003 Server: UDDI Services, el cual implementa un registro privado
UDDI que soporta el API 1.0 y 2.0 definido por el estándar.
Si bien en la implementación realizada este proceso es de invocación manual, en
una operación real de un servicio de directorio de e-Learning el proceso de
crawling debe ejecutarse de manera continua, repitiendo su lógica periódicamente,
con el fin de tratar de mantener actualizada la información del índice local.
• ServicioWebConsulta: Este es el servicio web del directorio, que a través de su
operación findServices permite a cualquier aplicación en Internet realizar
consultas por palabras claves de los servicios de e-Learning publicados (cuya
MISC-03-1-8
100
información básica ha sido descargada localmente en el índice por el proceso
anterior).
MISC-03-1-8
101
4. CONCLUSIONES
Recogiendo los esfuerzos de estandarización que se han presentado tecnológicamente
en los últimos años, como lo son el nuevo paradigma de los servicios web para el
desarrollo de aplicaciones distribuidas en Internet y el modelo de referencia SCORM en la
industria del e-Learning, esta tesis ha presentado un nuevo enfoque para el desarrollo de
soluciones de e-Learning que puedan ser fácilmente accedidas, reutilizadas,
dinámicamente ensambladas, y brinden una experiencia de aprendizaje personalizada a
las necesidades particulares de cada individuo: una arquitectura distribuida de e-Learning
basada en servicios web.
Al presentar este nuevo enfoque propuesto, se han descrito las características y
responsabilidades de cada uno de los roles participantes en esta arquitectura orientada al
servicio: proveedores, consumidores y el rol intermediario del directorio.
Para los proveedores de e-Learning, los servicios web, además de los beneficios que
ofrecen, crean nuevos modelos de negocios para la provisión de su material de
aprendizaje, como el e-Learning bajo demanda o el e-Learning por suscripción, que
fueron mencionados en el documento, y otros que pueden surgir en el futuro.
Para los consumidores, refiriéndose a las aplicaciones que hacen uso de los servicios y
no al usuario final de las mismas, se brinda una posibilidad de integración del aprendizaje
a su propia lógica de negocio y presentación. Esto es un factor de importancia para los
negocios, pues pueden brindar a sus usuarios experiencias de aprendizaje naturales y
transparentes en la medida en que están acopladas a los sistemas con los que
interactúan diariamente.
El último rol, el del directorio de servicios de e-Learning, sin ser estrictamente
imprescindible, presenta mecanismos útiles para el descubrimiento dinámico de los
recursos de aprendizaje necesarios por el individuo en algún instante en particular. En el
MISC-03-1-8
102
análisis realizado quedó evidenciado que los registros públicos de servicios web, como
UDDI, no proporcionan toda la semántica necesaria para búsquedas de servicios de e-
Learning y por lo tanto es necesario recurrir a nuevas alternativas para suplir esta función,
como la de un directorio especializado o un motor de búsqueda como servicio de valor
agregado.sobre los registros públicos existentes.
Adicionalmente, esta arquitectura propuesta podrá enriquecerse con el resultado de los
esfuerzos actuales de la industria en la definición de estándares que complementen la
base inicial de los servicios web en materia de seguridad, de transaccionalidad, de
comercio electrónico, entre otros, así como la evolución de los servicios web interactivos y
los estándares que los soportan como WSRP.
Es importante mencionar, como pudo verse a lo largo del documento, que el nuevo
enfoque propuesto cabe más dentro de lo tecnológico que lo pedagógico. Sin embargo,
no es la tecnología la que enseña. La tecnología brinda herramientas que ayudan a que
un diseño instruccional determinado, o una metodología pedagógica específica, brinden
una experiencia de aprendizaje efectiva a través del e-Learning. El enfoque propuesto
brinda un nuevo espectro de posibilidades tecnológicas para el desarrollo de soluciones
de e-Learning, con posibilidades de expresar sus elementos básicos como contenido,
evaluación y colaboración a través de servicios web, pero que aún deben ser creados y la
relación entre ellos debe ser coordinada con un enfoque pedagógico particular con el fin
de crear un todo coherente.
MISC-03-1-8
103
BIBLIOGRAFIA
[ADL, 01] Advanced Distributed Learning. Shareable Content Object Reference Model Version 1.2. The SCORM Overview [en línea] <http://www.adlnet.org> [Consulta 5 abr. 2003] [ADL2, 01] -----. Shareable Content Object Reference Model Version 1.2. The SCORM Content Aggregation Model [en línea] <http://www.adlnet.org> [Consulta 5 abr. 2003] [ADL3, 01] -----. Shareable Content Object Reference Model Version 1.2. The SCORM Run-Time Environment [en línea] <http://www.adlnet.org> [Consulta 5 abr. 2003] [ALIN, 03] Atlantic Learning Innovation Network. E-Business, E-Content, E-Networking, and E-Learning Concepts. [en línea] <http://sencen.ednet.ns.ca/main.nsf/c2ab3e531574a15084256a390065cd4d/534949a3ea3f2d3c84256cae000df828?OpenDocument> [Consulta 15 feb. 2003] [CTAL, 01] Comission on Technology and Adult Learning. A Vision of E-Learning for America’s Workforce. [en línea] < http://www.nga.org/cda/files/ELEARNINGREPORT.pdf> [Consulta 15 feb. 2003] [BARRON, 02] Barron, Tom. Evolving Business Models in e-Learning [en línea] mar. 2002 <http://www.sric-bi.com/LoD/summaries/EvolvBizModelsSum.shtml> [Consulta 10 ene. 2003] [BELLWOOD, 02] Bellwood, Tom. Understanding UDDI. Tracking the evolving specification [en línea] jul. 2002. <http://www-106.ibm.com/developerworks/library/ws-featuddi> [Consulta 12 jul. 2003] [DAVIES, 03] Davies, Phil. Simulation: bringing e-Learning to a new level. [en línea] jul. 2003. <http://www.computeruser.com/articles/2207,1,1,1,0701,03.html> [Consulta 26 ene. 2004] [DELOITTE, 02] Deloitte & Touche Corporate Finance LLC. Web Services. The next Evolution in Software [en línea] Marzo, 2002. <http://www.allidex.com/DTCF_Web_Services_Research_Report.pdf> [Consulta 1 feb. 2002] [EDUWORKS, 03] Eduworks Corporation. Learning Objects Tutorial. [en línea] <http://www.eduworks.com/LOTT/tutorial/index.html> [Consulta 29 mar. 2003]
MISC-03-1-8
104
[ELEARNING, 03] E-Learning? [en línea] <http://www.e-learningsite.com/elearning/indelea.htm> [Consulta 15 feb. 2003] [GREENBERG, 02] Greenberg, Leonard. LMS and LCMS: What’s the Difference [en línea] dic. 2003 <http://www.learningcircuits.org/2002/dec2002/greenberg.htm> [Consulta 14 jun. 2003] [HEKATE, 03] HEKATE: Higher Education Knowledge And Technology Exchange. Web Services Enabling Technology for Application Integration and Assembly. Jul. 2003 <http://www.hekate.org> [Consulta 4 may. 2003] [HILTZ, 03] Hiltz, Starr Roxanne. Collaborative Learning in Asynchronous Learning Networks; Building Learning Communities. [en línea] <http://eies.njit.edu/~hiltz/collaborative_learning_in_asynch.htm> [Consulta 22 feb. 2003] [IBM, 03] IBM Web Services Architecture Team. Web Services architecture overview. The next stage of evolution for e-business. [en línea] <http://www-106.ibm.com/developerworks/webservices/library/w-ovr/> [Consulta 1 feb. 2003] [KAPLAN, 02] Kaplan, Soren. Building Communities – Strategies for Collaborative Learning. [en línea] <http://www.learningcircuits.org/2002/aug2002/kaplan.html> [Consulta 22 feb. 2003] [LITWACK, 02] Litwack, David A. Web Services: The Biggest “Next Big Thing” of them all [en línea]. 10 jul. 2002. <http://webservicesadvisor.com/doc/10075> [Consulta 20 nov. 2002] [MICROSOFT, 02] Microsoft. A Platform for Web Services. [En línea] <http://msdn.microsoft.com/library/en-us/dnwebsrv/html/websvcs_platform.asp> [Consulta 1 feb. 2003] [MARTINEZ, 02] Martinez, Maggie. Beyond Classroom Solutions: New Design Perspectives for Online Learning Excellence. [en línea] <http://ifets.ieee.org/periodical/vol_2_2002/discuss_summary_january2002.html> [Consulta 15 feb. 2003] [MORTIMER, 02] Mortimer, Lori. (Learning) Objects of Desire: Promise and Practicality. [en línea] http://www.learningcircuits.org/2002/apr2002/mortimer.html [Consulta 15 feb. 2003] [OBRINGER, 02] Obringer, Lee Ann. How E-Learning Works [en línea] <http://www.howstuffworks.com/elearning1.htm> [Consulta 26 nov. 2002]
MISC-03-1-8
105
[RAJASEKHAURINI, 02] Rajasekhaurini, Syam. Web Services – Major Sigues. [en línea] <http://www.acs.org.au/nsw/westsyd/meetings/200207pres.pdf> [Consulta 1 feb. 2003] [RESHEF, 02] Reshef, Eilon. Building Interactive Web Services with WSIA & WSRP. Dic. 2003. [en línea] <http://www.webcollage.com/html/products/more_information/WebCollage_WSJ_WSIA_WSRP.pdf> [Consulta 15 jul. 2003] [SIEMENS, 03] Siemens, George. Assessment & Evaluation. Overview. [en línea] <http://www.elearnspace.org/assessmentevaluation.htm> [Consulta 23 feb. 2003] [SIEMENS2, 03] Siemens, George. Collaboration. [en línea] <http://www.elearnspace.org/Collaboration.htm> [Consulta 22 feb. 2003] [STEVENS, 03] Stevens, Michael. Service-Oriented Architecture Introduction, Part 1. <http://www.developer.com/design/article.php/10925_1010451_2> [Consulta 27 abr. 2003] [TARQUINO, 03] Tarquino Bojacá, Jaime. Motor de Búsqueda sobre UDDI. Tesis de grado de Magister. Universidad de los Andes, 2003. [THEBOARD, 01] The Board of Trustees of the University of Illinois. Strengths and Weaknesses of Online Learning [en línea] Illinois, 2001. < http://www.ion.illinois.edu/IONresources/onlineLearning/strengthAndWeak.asp> [Consulta: 15 nov. 2002] [WEBCOLLAGE, 03] WebCollage. Interactive Web Services: Architecture Whitepaper. [en línea] <http://www.webcollage.com/html/products/more_information/WebCollage_Interactive_Web_Services_Architecture_Whitepaper_2003.pdf> [Consulta 15 jul. 2003] [WEB SERVICES, 02] Web Services, Part I: Introduction: Motivation behind Web Services. [en línea] <http://www.webreference.com/js/column96/2.html> [Consulta 11 nov. 2002]
MISC-03-1-8
106
ANEXOS
MISC-03-1-8
107
ANEXO 1. CARACTERÍSTICAS TECNICAS DE LA HERRAMIENTA WEBCOLLAGE
SYNDICATOR56
WebCollage Syndicator for Portlets es una solución de software de servicios web
interactivos, diseñada para soportar todo el proceso de compartir aplicaciones web
interactivas y procesos de negocio con otras aplicaciones, en el que se pueden identificar
las siguientes tareas:
• Empaquetamiento de una aplicación web con un Servicio Web
• Distribución del Servicio Web a múltiples aplicaciones
• Integración del Servicio Web en tiempo real dentro del ambiente de las
aplicaciones consumidoras.
• Análisis de la interacción del usuario con el Servicio Web.
La solución ofrece una plataforma de servidor, diseñada para operar sobre cualquier
infraestructura web. Está compuesta de tres componentes:
• WebCollage Provider Center: una interfaz gráfica web que ayuda en la creación
y definición de módulos web (llamados portlets), y permite la administración
transparente del repositorio del portal.
• WebCollage Portlet Repository: almacena meta-información sobre los módulos
creados y definidos por el usuario, así como la información sobre la aplicación web
que ha sido transformada en un portlet.
• WebCollage Syndicator Server: un servidor que expone los módulos web, para
que sean integrados en otras aplicaciones o portales.
MISC-03-1-8
108
¿Cómo funciona? Web Collage Syndicator for Portlets recibe invocaciones SOAP WSRP57 a través de
HTTP provenientes de una aplicación consumidora (un portal, por ejemplo).
Si la invocación recibida solicita alguno de los módulos web (portlets) disponibles,
WebCollage Syndicator responde a la solicitud haciendo uso de la información
disponible en el repositorio (Repository). Si la solicitud es por un fragmento de página o es
el resultado de la interacción del usuario con un portlet, WebCollage Syndicator utiliza la
información del repositorio para determinar la página adecuada que se le debe enviar a la
aplicación. A continuación, cualquiera que sea el caso, el sistema:
1. Realiza una invocación (request) HTTP a la aplicación web maestra subyacente.
2. Recibe la respuesta HTML de la aplicación, y la transforma con el fin de que pueda
ser agregada o incorporada a la aplicación consumidora. Esto incluye
transformaciones de las hojas de estilo CSS, JavaScript, y todos los hipervínculos
HTML encontrados con el fin de que sean conformes a la especificación WSRP.
3. Adapta el HTML basado en las propiedades de personalización enviadas a través
de WSRP por la aplicación consumidora.
4. Transforma varias directivas HTTP retornadas por la aplicación web maestra
(como Cookies y Caché) en directivas WSRP.
5. Incorpora el código HTML resultante dentro de una respuesta SOAP WSRP y la
retorna a la aplicación consumidora.
Visto de este modo, WebCollage Syndicator for Portlets es un servidor que traduce
invocaciones WSRP (provenientes de la aplicación consumidora del servicio web
interactivo) a HTTP (las cuales envía a la aplicación web maestra), y viceversa. Por lo
tanto, el servidor reside entre la aplicación consumidora y la aplicación web.
56 Traducido del documento “WebCollage Syndicator For Portlets. Technical Overview”, que se adjunta digitalmente a este documento (Syndicator For Portlets Tecnical Overview.PDF) 57 La versión de evaluación con la que se trabajó en la implementación no soporta aún WSRP.
MISC-03-1-8
109
La siguiente figura ilustra esta arquitectura de la plataforma de WebCollage Syndicator for Portlets.
Figura 33. Arquitectura de la Plataforma WebCollage Syndicator for Portlets
Mayor información de la herramienta se puede encontrar en el sitio web
http://www.webcollage.com
HTTP(S)
WSRP
WSRP WSRP
WSRP
WSRP
MISC-03-1-8
110
ANEXO 2. ¿QUÉ ES APRENDAHACIENDO?
Una de las pioneras en América Latina, AprendaHaciendo, una empresa colombiana
especializada en el campo del e-Learning, es el resultado de la experiencia y el
conocimiento de dos compañías, CompuAulas Ltda. y Conocer Ltda., dedicadas desde
hace más de una década al desarrollo de habilidades y entrenamiento de profesionales en
el área de tecnologías de información (TI) y responsables de la implementación exitosa de
estos programas, para miles de clientes, a nombre de importantes empresas
transnacionales como AT&T, IBM, Microsoft, NCR, Oracle y UNISYS, entre otras.
AprendaHaciendo pone el dominio de las nuevas tecnologías y el desarrollo de
metodologías efectivas de transferencia de conocimiento al servicio de las necesidades
específicas de sus clientes en materia de capacitación y desarrollo de talento.
Los productos de AprendaHaciendo constituyen una novedosa y probada solución de
aprendizaje, que de forma interactiva, práctica y efectiva dirige la construcción de
habilidades y conocimientos alineados con las metas y estrategias de las empresas. Su
metodología de enseñanza, basada en cápsulas de aprendizaje58, ofrece una reducción
aproximada del 40% en el tiempo de aprendizaje, mientras incrementa de un 40% a un
70% el nivel de retención en comparación con los métodos tradicionales.
Su método tradicional de distribución de cursos se hace a través de Internet, Intranets o
en CD y están diseñados para operar en red o en forma aislada, lo que permite la
implantación exitosa en cualquier ambiente. Los servicios web de e-Learning analizados
en este documento proporcionan a AprendaHaciendo un nuevo mecanismo a través del
cual puede distribuir sus soluciones de aprendizaje y la habilitan para la práctica de
nuevos modelos de negocio.
Mayor información sobre AprendaHaciendo puede encontrarse en su portal web
http://www.aprendahaciendo.com
58 Una “cápsula de aprendizaje” es la materialización en AprendaHaciendo del enfoque de Learning Objects analizado en esta tesis.
MISC-03-1-8
111
ANEXO 3. DESCRIPCIÓN DEL CONTENIDO DEL CD QUE ACOMPAÑA A ESTE DOCUMENTO
A continuación se brinda una descripción del contenido de la carpeta PROTOTIPOS
existente en CD que acompaña al material digital de este documento.
• TOOLS: Este subdirectorio contiene los instaladores de las herramientas
adicionales utilizadas en la implementación de los prototipos: una versión de
evaluación de WebCollage Syndicator, Microsoft Web Services Enhancements 1.0 (que permitió la implementación de DIME en el servicio web de contenido) y la
librería Microsoft UDDI SDK 2.0 para interactuar con las APIs de UDDI.
• PROVEEDOR: Este subdirectorio contiene la implementación de los servicios web
de e-Learning prototipo de AprendaHaciendo.
o METADATA: Carpeta con un proyecto de librería de clases de Visual
Studio .NET, que contiene la implementación de la lógica para la
manipulación de metadatos SCORM.
o SERVICIOWEBCONTENIDO: Carpeta con un proyecto de Servicio Web
ASP .NET de Visual Studio .NET, con la implementación de un servicio
web de contenido que cumple con la interfaz descrita en el documento.
SCORM: En este subdirectorio del servicio web de contenido se
encuentran almacenadas las cápsulas del Curso Básico de Excel
XP que se seleccionaron para efectos del prototipo (en el
subdirectorio CAPSULAS), así como el manifiesto SCORM del
servicio (el archivo imsmanifest.xml).
o EVALUACIONES: Contiene los archivos necesarios para la
implementación del servicio web interactivo de Evaluación
MISC-03-1-8
112
EVALUACIONEXCEL: Contiene la aplicación web de evaluación,
desarrollada con Visual Studio .NET, que es exportada como un
servicio web interactivo.
CONFIGURACIONSYNDICATOR: Contiene los archivos de
configuración que deben copiarse al directorio de instalación de la
herramienta WebCollage Syndicator, para exponer la aplicación
web de evaluación como un servicio web interactivo.
• CLIENTES: Este subdirectorio contiene prototipos de aplicaciones consumidoras
de servicios web de e-Learning
o BROKEREVALUACION: Contiene una aplicación web ASP .NET,
desarrollada con Visual Studio .NET que sirve como intermediario en la
invocación al servicio web interactivo de evaluación.
o AGENTEELEARNING: Aplicación Windows que reside en la bandeja del
sistema del escritorio del estudiante con la lista de cápsulas personalizadas
de acuerdo con los resultados previos de evaluaciones presentadas.
• DIRECTORIO: Implementación de un directorio de servicios de e-Learning como
un motor de búsqueda que opera sobre UDDI.
o BDINDICE: Este subdirectorio contiene los archivos con los dispositivos de
datos y de log de transacciones de la base de datos de SQL Server 2000
utilizada para almacenar la información descargada por el crawler de
servicios web de e-Learning.
