0

2010-05-21 (uam) uned remote lab

1,248

Published on

2010-05-21
Sem eMadrid
(UAM)
Manuel Castro
Elio San Cristóbal
UNED
remote labs

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,248
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
38
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "2010-05-21 (uam) uned remote lab"

  1. 1. HACIA UNA SOLUCIÓN E-LEARNING GLOBAL: INTEGRACIÓN DE SISTEMAS DE GESTIÓN DE APRENDIZAJE Y LABORATORIOS VIRTUALES Y REMOTOS Manuel-Alonso Castro Gil y Elio San Cristóbal Ruiz Departamento de Ingeniería Eléctrica, Electrónica y de Control (UNED) (mcastro@ieec.uned.es y elio@ieec.uned.es)
  2. 2. ÍNDICE  Introducción  Situación Actual  Sistemas de Gestión del Aprendizaje  Laboratorios Virtuales  Problemática actual  Proyecto iLab (MIT)  Arquitectura Propuesta  Trabajos Realizados  Trabajos Futuros  Conclusión
  3. 3. INTRODUCCIÓN La educación a distancia a través de Internet (online) ha experimentado en los últimos años un gran crecimiento  En Estados Unidos, unos 3,9 millones de personas estudiaban en 2007 algún curso de educación superior virtualmente  En España, aproximadamente el 30% de la oferta de programas de posgrado es ya online, según datos del Instituto Universitario de Posgrado
  4. 4. INTRODUCCIÓN UNED  Universidad a Distancia  Modelo mixto  Educación personalizada (blended learning)  Estudiantes en todo el ámbito nacional y mundial  Necesidad de una metodología de aprendizaje adecuada También hay estudiantes en: • Europa • América
  5. 5. INTRODUCCIÓN Existen asignaturas donde los alumnos deben:  Adquirir conocimiento teórico  Adquirir conocimiento práctico o habilidades ¿Cómo adquirir ambos conocimientos en una universidad a Distancia? Utilización de herramientas e-learning
  6. 6. ÍNDICE  Introducción  Situación Actual  Sistemas de Gestión del Aprendizaje  Laboratorios Virtuales  Problemática actual  Proyecto iLab (MIT)  Arquitectura Propuesta  Trabajos Realizados  Trabajos Futuros  Conclusión
  7. 7. SITUACIÓN ACTUAL Existen algunas soluciones e-learning destinadas a enseñar conocimiento práctico y teórico  Conocimiento teórico  Páginas Web  Wikis  LMS (Iniciativa privada o Código abierto)  Conocimiento práctico  laboratorios virtuales (laboratorios software, web, remotos)
  8. 8. ÍNDICE  Introducción  Situación Actual  Sistemas de Gestión del Aprendizaje  Laboratorios Virtuales  Problemática actual  Proyecto iLab (MIT)  Arquitectura Propuesta  Trabajos Realizados  Trabajos Futuros  Conclusión
  9. 9. SITUACIÓN ACTUAL (LMS) Sistemas de Gestión de Aprendizaje o LMS. Permiten mostrar y organizar el conocimiento de acuerdo con los objetivos propuestos por el profesor. Para ello:  Servicios y Aplicaciones  Autenticación  Comunicaciones asíncronas (foros, correo, etc.)  Comunicaciones síncronas (chats, etc.)  Herramientas de evaluación (test, etc.)  Seguimiento de Alumnos  Estándares e-learning. Ejemplos  De contenido (LO, IMS-packing, SCORM)  De evaluación (IMS-QTI)
  10. 10. SITUACIÓN ACTUAL (LMS) Estos estándares e-learning permiten: o Descripción de contenidos (IEEE-LOM, Dublin CORE) • Búsqueda y recuperación de contenidos o Reutilización de contenido (paquetes IMS, SCORM) o Reutilización de tipos de preguntas y de pruebas de evaluación (IMS-QTI) o Diseñar y reutilizar procesos de aprendizaje (IMS-LD)
  11. 11. SITUACIÓN ACTUAL (LMS)
  12. 12. SITUACIÓN ACTUAL (LMS) Actualmente existen un gran número de LMS en el Mercado. Estos pueden ser:  Iniciativa Privada (Blackboard, etc.)  Para que una institución pueda instalarla deberá pagar por ello  La modificación de código, para adaptarla a nuevas necesidades es casi exclusivo de la empresa creadora  Nuevas versiones >>> integrables con aplicaciones externas  Código abierto (Moodle, dotLRN, Sakai, etc. )  No es necesario pagar por ella  Es posible conocer su arquitectura y programación, por tanto, es posible crear y adaptarla a las necesidades de cada institución
  13. 13. ÍNDICE  Introducción  Situación Actual  Sistemas de Gestión del Aprendizaje  Laboratorios Virtuales  Laboratorios SW  Laboratorios Web  Laboratorios Remotos  Problemática actual  Proyecto iLab (MIT)  Arquitectura Propuesta  Trabajos Realizados  Trabajos Futuros  Conclusión
  14. 14. SITUACIÓN ACTUAL (LABORATORIOS) Los Laboratorios Virtuales ofrecen la posibilidad de adquirir conocimiento práctico desde cualquier lugar y en cualquier momento
  15. 15. SITUACIÓN ACTUAL (LABORATORIOS) Laboratorio Logs Interfaz de Usuario Servicio de reservas Gestión de Logs de Experimentos Autenticación Grupos y Gestión de Perfiles Contenidos (No SCORM…) Herramientas de Comunicación Herramientas de Evaluación
  16. 16. SITUACIÓN ACTUAL (LABORATORIOS) Actualmente se pueden dividir los laboratorios en tres Grupos:  Laboratorios Software  Laboratorios Web  Laboratorios Remotos
  17. 17. ÍNDICE  Introducción  Situación Actual  Sistemas de Gestión del Aprendizaje  Laboratorios Virtuales  Laboratorios SW  Laboratorios Web  Laboratorios Remotos  Problemática actual  Proyecto iLab (MIT)  Arquitectura Propuesta  Trabajos Realizados  Trabajos Futuros  Conclusión
  18. 18. SITUACIÓN ACTUAL (LABORATORIOS) Laboratorios Software es un programa de ordenador que simula sistemas, dispositivos y situaciones del mundo real
  19. 19. SITUACIÓN ACTUAL (LABORATORIOS) Laboratorios Software (Ventajas)  Existen sistemas demasiado caros para que cualquier organización o universidad disponga de ellos  Los estudiantes pueden instalar el software en cualquier ordenador y realizar sus prácticas en cualquier momento y lugar (24 horas al día, 7 días a la semana y 365 días al año)  Los programas de simulación permiten:  Al profesor, diseñar experimentos que puedan dañar el sistema.  Al estudiante, realizar sus prácticas sin temor de poder equivocarse y provocar algún daño a los dispositivos
  20. 20. SITUACIÓN ACTUAL (LABORATORIOS) Laboratorios Software (Desventajas)  El estudiante no trabaja con dispositivos reales  Problemas de versiones. Para evitar esto:  No existen herramientas colaborativas  No existe posibilidad de que el tutor pueda evaluar de forma continua los progresos realizados por el estudiante Estudiante 1. Instalar SW en el PC del estudiante 2. Realizar los experimentos, utilizando dicho software Servidor Web Internet Nuevas versiones del laboratorio
  21. 21. SITUACIÓN ACTUAL (LABORATORIOS) Laboratorios Software (Ejemplos) • VLabQ. Es un simulador interactivo de prácticas de laboratorio de Química Herramientas y menús para realizar la práctica Cambiar la velocidad de simulación Práctica realizada por el alumno Documento del profesor que explica como realizar la práctica y posteriormente le pregunta sobre los resultados obtenidos
  22. 22. SITUACIÓN ACTUAL (LABORATORIOS) Laboratorios Software (Ejemplos) • RCSim. Es un simulador de circuitos resistivos, permite el diseño del circuito Herramientas para diseñar el circuito Iniciar y parar simulación del circuito Circuito que se ha creado
  23. 23. ÍNDICE  Introducción  Situación Actual  Sistemas de Gestión del Aprendizaje  Laboratorios Virtuales  Laboratorios SW  Laboratorios Web  Laboratorios Remotos  Problemática actual  Proyecto iLab (MIT)  Arquitectura Propuesta  Trabajos Realizados  Trabajos Futuros  Conclusión
  24. 24. SITUACIÓN ACTUAL (LABORATORIOS) Laboratorios Web El estudiante no necesita instalar el programa de simulación en su ordenador, tal vez algún plug-in. Un servidor web, que es el encargado de servir el programa de simulación. Es necesario un PC con conexión a Internet Estudiante Estudiante Internet Servidor Web 1. Navegador Web 2. Applet de Java o aplicación Web del laboratorio 1. Servicios Web a) Registro de usuarios b) Herramientas de comunicación, etc. 2. Laboratorio virtual (parte Servidor)
  25. 25. SITUACIÓN ACTUAL (LABORATORIOS) Laboratorios Web (Ventajas)  Existen sistemas demasiado caros para que cualquier organización o universidad disponga de ellos  Acceso en cualquier ordenador y realizar sus prácticas en cualquier momento y lugar (24 horas al día, 7 días a la semana y 365 días al año)  El servidor web, aparte de proporcionar el programa de simulación, ofrece herramientas de:  Autenticación  Comunicación  Síncrona (chat, etc.)  Asíncrona (foros, etc.)  Permite al profesor seguir los progresos de los estudiantes. Logs y de los resultados de sus experimentos
  26. 26. SITUACIÓN ACTUAL (LABORATORIOS) Laboratorios Web (Desventajas)  La principal desventaja es que el estudiante no trabaja con sistemas reales. Programas de simulación
  27. 27. SITUACIÓN ACTUAL (LABORATORIOS) Laboratorios Web (Ejemplos)  Laboratorio Web DIEEC (UNED). Que permite a un estudiante simplificar funciones lógicas por el método de Karnaugh (Applet de java)
  28. 28. SITUACIÓN ACTUAL (LABORATORIOS) Laboratorios Web (Ejemplos)  La web “fisquiweb” destinada al aprendizaje de la física y química, ofrece un conjunto de material didáctico y de laboratorios para el aprendizaje de esta asignatura (FLASH)
  29. 29. ÍNDICE  Introducción  Situación Actual  Sistemas de Gestión del Aprendizaje  Laboratorios Virtuales  Laboratorios SW  Laboratorios Web  Laboratorios Remotos  Problemática actual  Proyecto iLab (MIT)  Arquitectura Propuesta  Trabajos Realizados  Trabajos Futuros  Conclusión
  30. 30. SITUACIÓN ACTUAL (LABORATORIOS) Laboratorios Remotos El estudiante se conecta a un servidor web, este le mostrará las imágenes reales de los instrumentos que va a manejar, las acciones que puede realizar y los resultados de esas acciones Servidor de Audio/video Servidor de Base de datos ? ? Instrumentos Estudiante Estudiante Internet Servidor Web 1. Permite almacenar a) Los datos del usuario b) Datos del experimento, etc. Controlador El controlador va enviar las ordenes a los instrumentos y recibir los resultados de la ejecución de estos comandos. 1. Navegador Web 2. Applet de Java o aplicación Web del laboratorio 1. Servicios Web a) Registro de usuarios b) Herramientas de comunicación, etc. 2. Laboratorio virtual (parte Servidor)
  31. 31. SITUACIÓN ACTUAL (LABORATORIOS) Laboratorios Remotos (Ventajas)  Instrumentos reales, no con programas de simulación.  Acceso en cualquier momento y lugar  Para acceder a estos laboratorios se crean un conjunto de servicios:  Autenticación.  Autorización. Una vez autenticado hay que comprobar a que experimentos tiene acceso  Comunicación (Chats, foros, e-mail, etc.)  Reservas. Dos de los métodos más utilizados actualmente son:  gestión de colas  gestión de un calendario  seguimiento de los progresos de los usuarios  logs y de los resultados de sus experimentos
  32. 32. SITUACIÓN ACTUAL (LABORATORIOS) Laboratorios Remotos (Desventajas)  Es importante diseñar e implementar de manera correcta los experimentos que va a hacer el estudiante. Al manejar instrumentos reales, cualquier operación inadecuada podría dañar el instrumento o instrumentos  Aún con la mejora en las conexiones de red, es importante definir bien los formatos de video y audio. Evitando retrasos o perdidas de audio y video no deseadas
  33. 33. SITUACIÓN ACTUAL (LABORATORIOS) Laboratorios Remotos (Ejemplos)  WebLab-PLD. Es utilizado en la asignatura de lógica programable de la Universidad de Deusto
  34. 34. SITUACIÓN ACTUAL (LABORATORIOS) Laboratorios Remotos (Ejemplos)  Laboratorio es obtener las curvas características de: Diodo en polarización directa, Diodo Zener (Universidad de Rosario, Argentina)
  35. 35. SITUACIÓN ACTUAL (LABORATORIOS) Laboratorios Remotos (Ejemplos)  VISIR Instituto de Tecnología Blekinge (Suecia) Estudiante Mesa de trabajo Placa simulada Matriz de conmutación
  36. 36. SITUACIÓN ACTUAL (LABORATORIOS) Laboratorios Remotos (Ejemplos)  Planta hidráulica del DIEEC (UNED)
  37. 37. ÍNDICE  Introducción  Situación Actual  Sistemas de Gestión del Aprendizaje  Laboratorios Virtuales  Laboratorios SW  Laboratorios Web  Laboratorios Remotos  Problemática actual  Proyecto iLab (MIT)  Arquitectura Propuesta  Trabajos Realizados  Trabajos Futuros
  38. 38. SITUACIÓN ACTUAL (PROBLEMÁTICA) LMS y Laboratorios Virtuales  Cada solución implementa sus propios servicios de:  Autenticación  Autorización  Comunicación (chats, e-mail, foros, etc.)  Herramientas de Evaluación NO existe reutilización de Servicios
  39. 39. SITUACIÓN ACTUAL (PROBLEMÁTICA) LMS y Laboratorios Virtuales  Los LMS utilizan estándares e-learning. Los Laboratorios NO. Por tanto, en los laboratorios:  No existe reutilización de contenidos  Reutilización de procesos de aprendizaje  Reutilización de preguntas y evaluaciones
  40. 40. SITUACIÓN ACTUAL (PROBLEMÁTICA) LMS Laboratorio Autenticación Base de Datos Logs Grupos y Gestión de Perfiles Seguridad Herramientas de Evaluación (IMS-QTI…) Herramientas de Grupo Contenidos (SCORM, IMS…) Interfaz de Usuario Servicio de reservas Gestión de Logs de Experimentos Autenticación Grupos y Gestión de Perfiles Contenidos (No SCORM…) Herramientas de Comunicación Herramientas de Comunicación Herramientas de Evaluación
  41. 41. ÍNDICE  Introducción  Situación Actual  Sistemas de Gestión del Aprendizaje  Laboratorios Virtuales  Problemática actual  Proyecto iLab (MIT)  Arquitectura Propuesta  Trabajos Realizados  Trabajos Futuros  Conclusión
  42. 42. PROYECTO ILAB (MIT)  Cada institución desarrolla su propios laboratorios. Por tanto:  Existen dificultades para compartir laboratorios  Usuarios de diversas instituciones puedan usar laboratorios de otra  No existía una Arquitectura para de comunicación para compartir laboratorios Proyecto iLab del MIT
  43. 43. PROYECTO ILAB (MIT) El Instituto tecnológico de Massachusetts (MIT) junto con Microsoft y Agilent Technologies inició el proyecto iLab en el año 2000 con el objetivo de establecer un marco de trabajo que facilitará el desarrollo, gestión y compartición de laboratorios remotos online (“iLabs”)  Tipos de Experimentos  Batch o por lotes  Interactivos
  44. 44. PROYECTO ILAB (EXPERIMENTOS) Experimentos Batch o por Lotes. El estudiante, antes que empiece el experimento, especifica todos los parámetros que gobiernan la ejecución  Se asemeja a la arquitectura de negocio web basada en tres capas
  45. 45. PROYECTO ILAB (EXPERIMENTOS) Arquitectura básica de iLab  El cliente del laboratorio. Que no es más que la interfaz de usuario para el laboratorio online o iLab  El servidor del laboratorio conecta con el hardware del laboratorio y gestiona el experimento enviado por el usuario.  El servicio Broker. es responsable de proporcionar las funcionalidades comunes para todos los laboratorios online, como:  Autenticación  Autorización  Almacenamiento de experimentos
  46. 46. PROYECTO ILAB (EXPERIMENTOS) Dispositivos del Laboratorio Servidor del Laboratorio Internet Servicio Broker Base de datos Internet / Intranet Cliente o Estudiante Cliente o Estudiante
  47. 47. PROYECTO ILAB (EXPERIMENTOS) En un experimento interactivo el estudiante configura una serie de parámetros, inicia el experimento y luego monitoriza su desarrollo, pudiendo cambiar los parámetros de control si es necesario  Es necesario que el estudiante y el servidor de laboratorio puedan enviar y recibir datos directamente
  48. 48. PROYECTO ILAB (EXPERIMENTOS) Elementos de la arquitectura interactiva  Servicio de almacenamiento de experimentos (no en servicio Broker)  Servicio de planificación (Reservas)  El servicio Broker es responsable de la autenticación del usuario y el uso autorizado de los recursos del servidor del laboratorio
  49. 49. PROYECTO ILAB (EXPERIMENTOS)
  50. 50. PROYECTO ILAB (RESUMEN)  iLab Permite la reutilización y compartición de laboratorios entre instituciones.  Continúan creándose servicios ya existente en los LMS  No se utilizan estándares e-learning
  51. 51. PROYECTO ILAB (RESUMEN) Global Online Laboratory Consortium  Consorcio para promover la compartición y desarrollo de la boratorios remotos para la educación  Participantes:  Massachusetts Institute of Technology, (Estados Unidos)  University of Queensland, (Australia)  University of Technology, Sydney, (Australia)  Carinthia University of Applied Sciences, (Austria)  Universidad de Stuttgart  Universidad de Deusto, (España)  Departamento de Ingeniería Electrica, Electrónica y de Control (UNED), (España)
  52. 52. PROYECTO ILAB (RESUMEN)
  53. 53. ÍNDICE  Introducción  Situación Actual  Proyecto iLab (MIT)  Arquitectura Propuesta  Capa Cliente  Capa LMS  Capa del servidor de laboratorio  Capa de comunicaciones  Trabajos Realizados  Trabajos Futuros  Conclusión
  54. 54. ARQUITECTURA PROPUESTA Crear una arquitectura que de una solución única y Permita  Compartir y reutilizar laboratorios  Reutilizar los servicios de los LMS  Autenticación  Autorización  Comunicaciones (Chats, foros, etc.)  Utilizar de estándares e-learning  Reutilizar contenidos  Reutilizar evaluaciones
  55. 55. ARQUITECTURA ACTUAL LMS Laboratorio Autenticación Base de Datos Logs Grupos y Gestión de Perfiles Seguridad Herramientas de Evaluación (IMS-QTI…) Herramientas de Grupo Contenidos (SCORM, IMS…) Interfaz de Usuario Servicio de reservas Gestión de Logs de Experimentos Autenticación Grupos y Gestión de Perfiles Contenidos (No SCORM…) Herramientas de Comunicación Herramientas de Comunicación Herramientas de Evaluación
  56. 56. ARQUITECTURA PROPUESTA LMS Laboratorio Autenticación Base de Datos Logs Grupos y Gestión de Perfiles Seguridad Herramientas de Evaluación (IMS-QTI…) Herramientas de Grupo Contenidos (SCORM, IMS…) Interfaz de Usuario Servicio de reservas Gestión de Logs de Experimentos Autenticación básica Herramientas de Comunicación
  57. 57. ARQUITECTURA PROPUESTA Capas de la arquitectura  Capa cliente  Capa del LMS  Capa de comunicación entre LMS y Laboratorio  Capa laboratorio
  58. 58. ARQUITECTURA PROPUESTA Internet Estudiante Estudiante Internet Servidor Broker Base de datos LMS M I D D L E W A R E Internet Gestión de Conocimiento: - Servicios de administración - Paquetes de contenido - Herramientas de comunicación síncronas y asíncronas - Herramientas colaborativas - Logs y resultados de los experimentos - Evaluación Estándars e-learning (LOM, SCORM, IMS, QTI, etc.) Internet ? ? Instrumentos Controlador Laboratorio Software ? ? Instrumentos Controlador Laboratorio Software 1. Navegador Web 2. Applet de Java o aplicación Web del laboratorio
  59. 59. ÍNDICE  Introducción  Situación Actual  Proyecto iLab (MIT)  Arquitectura Propuesta  Capa Cliente  Capa LMS  Capa del servidor de laboratorio  Capa de comunicaciones  Trabajos Realizados  Trabajos Futuros  Conclusión
  60. 60. CAPA CLIENTE  El usuario  necesita un navegador web que muestre las aplicaciones web con las que se va a trabajar. Dependiendo de la aplicación, el usuario deberá instalar algún plug-in en el navegador Perfiles de usuario:  Administrador del LMS  Administrador del curso  Miembro del curso
  61. 61. CAPA CLIENTE  Administrador del LMS Administrador del LMS Gestionar laboratorios LMS Gestionar tipos laboratorio Gestionar acceso laboratorio Crear curso Gestión laboratorios «extends» «extends» «extends» «extends» «uses»«uses»
  62. 62. CAPA CLIENTE  Administrador del curso Administrador del curso Gestionar laboratorios-curso gestionar servicios y herramientas del curso Gestión laboratorios en el curso «extends» «extends» «extends» Utilizar laboratorios
  63. 63. CAPA CLIENTE  Miembro del curso Miembro de un curso «extends» Estudiante «extends» Profesor Usar servicios y herramientas LMS «extends» Utilizar laboratorios
  64. 64. ÍNDICE  Introducción  Situación Actual  Proyecto iLab (MIT)  Arquitectura Propuesta  Capa Cliente  Capa LMS  Capa del servidor de laboratorio  Capa de comunicaciones  Trabajos Realizados  Trabajos Futuros  Conclusión
  65. 65. CAPA LMS  El LMS es el encargado de atender las peticiones de usuario y de mostrar el contenido de aprendizaje de una forma ordenada y controlada Usuario Petición Servidor Base de Datos Plantillas Servicios Respuesta
  66. 66. CAPA LMS  Los componentes de la arquitectura del LMS son:  Gestor de Base de Datos. Contiene la información (usuarios, cursos, evaluaciones, copias de seguridad de los cursos, etc.) que da soporte a las herramientas y servicios del LMS  Los módulos o paquetes que representan la lógica de cada uno de los servicios y herramientas del LMS. (Depende del LMS)  Un servidor web, encargado de mostrar al usuario las páginas Web necesarias para mostrar los contenidos y utilizar las herramientas y servicios ofrecidos por el LMS
  67. 67. CAPA LMS Lado del LMS Aplicaciones y Servicios ServidorWeb Nuevas aplicaciones y servicios (creación del modelo de datos, lógica de la aplicación e interfaz de usuario) ServiciosWebPáginasWebdinámicasoestáticas Base de datos
  68. 68. CAPA LMS  Para realizar estas modificaciones, es necesario conocer la arquitectura y programación del LMS  Nos centramos en los LMS de código abierto, como:  Moodle  dotLRN  Sakai  Claroline  Dokeos
  69. 69. ÍNDICE  Introducción  Situación Actual  Proyecto iLab (MIT)  Arquitectura Propuesta  Capa Cliente  Capa LMS  Capa del servidor de laboratorio  Capa de comunicaciones  Trabajos Realizados  Trabajos Futuros  Conclusión
  70. 70. CAPA SERVIDOR DEL LABORATORIO  Conecta con el hardware del laboratorio y gestiona la ejecución del experimento enviado por el usuario. Deberá contener los servicios web para comunicarse con el LMS  En el caso del servicio broker del MIT, este también deberá contener los servicios necesarios para que el LMS pueda comunicarse con él
  71. 71. ÍNDICE  Introducción  Situación Actual  Proyecto iLab (MIT)  Arquitectura Propuesta  Capa Cliente  Capa LMS  Capa del servidor de laboratorio  Capa de comunicaciones  Trabajos Realizados  Trabajos Futuros  Conclusión
  72. 72. CAPA DE COMUNICACIÓN  Es necesario intercambiar información entre el LMS y el servidor de laboratorios. A través de Internet  Actualmente una de las soluciones más importantes es la utilización de servicios Web. Que proporcionan  Interoperabilidad entre aplicaciones independientemente del lenguaje utilizado o de la plataforma en que se ejecutan  Utilizan estándares como XML, SOAP, WDSL o UDDI  Los servicios web se apoyan en el protocolo HTTP y por tanto pueden acceder a otros sistemas de otras organizaciones sin quedarse “atrapados” en los filtros de seguridad de los firewalls
  73. 73. CAPA DE COMUNICACIÓN  Dos de las Arquitecturas de servicios Web más extendidas son:  SOAP . Es un protocolo basado en XML cuyo objetivo es intercambiar información estructurada en un entorno distribuido y descentralizado  REST. Es una arquitectura enfocada a un acceder a los recursos de un manara sencilla y sin estado
  74. 74. CAPA DE COMUNICACIÓN  SOAP <SOAP-ENV:Envelope <env:Header> (Opcional) <env:Body> (Requerido) Cliente SOAP Servicio SOAP Petición SOAP Respuesta SOAP HTTP HTTP
  75. 75. CAPA DE COMUNICACIÓN  REST. RESTfull HTTP utiliza los cuatro métodos fundamentales de HTTP GET, PUT, POST y DELETE Cliente Servicio Web GET /libro/?ISBN=12 getLibro(12) Respuesta (XML, JSON, etc.)
  76. 76. CAPA DE COMUNICACIÓN Aspectos SOAP REST Tecnológicos Enfocado en el diseño de aplicaciones integradas. (orquestación, composición mediante procesos de negocio) Enfocado en escalabilidad y desarrollo a gran escala de sistemas hipermedia distribuidos (Mashups, URI) Protocolos Varios protocolos (HTTP, SMTP,…) Solo HTTP Descripción del Servicio Especificaciones WSDL 1.1. y 2.0 Confía en entregar documentos claramente entendibles. Aun así, puede utilizar WADL Seguridad WS-Security Seguridad sobre HTTP Herramientas Existen un gran número de herramientas para crear estos servicios No es necesario herramientas
  77. 77. CAPA DE COMUNICACIÓN  SOA (Arquitectura Orientada a Servicios)  Más que una arquitectura es una aproximación o idea de pensar que lidera ciertas decisiones a la hora de diseñar una arquitectura software. Aspectos:  Aunque los servicios internamente son técnicos, deben disponer de una interfaz que sea comprensible por cualquier persona  Interoperabilidad (sistemas heterogéneos)  Débilmente acoplados (Flexibilidad, escalabilidad, tolerancia a fallos)
  78. 78. CAPA DE COMUNICACIÓN  SOA no está ligada a una tecnología en concreto, pero si se utiliza la tecnologías existentes para desarrollarla  SOAP, WSDL, UDDI  REST y WADL Consumidor del Servicio Repositorio UDDI Proveedor del Servicio BuscarW SD L SOAP UDDI W SD L Publicar
  79. 79. CAPA DE COMUNICACIÓN  A parte del registro de servicios, la búsqueda y utilización de estos. SOA introduce el concepto de orquestación o proceso de negocio (BPEL)
  80. 80. CAPA DE COMUNICACIÓN  ESB permiten comunicar gran variedad de sistemas y arquitecturas heterogéneas  Además de las características ofrecidas por SOA , los ESB:  Transformación de datos  entenderse, aún cuando los tipos de datos son diferentes para cada uno  Enrutamiento. Enviar la petición al servicio correcto o a la máquina que en ese momento está menos ocupada  Manejo de versiones. Para resolver de forma automática posibles cambios en los servicios publicados en el ESB  Seguridad. Establecer mecanismos de seguridad para las peticiones y respuestas  Monitorización del flujo de información que viaja por el ESB
  81. 81. CAPA DE COMUNICACIÓN  Aplicación a LMS y Laboratorios  LMS están empezando a soportar SOAP y REST  Servidores de laboratorios con diferentes arquitecturas  Permite la coreografía de servicios. Imaginemos que un experimento pudiera trabajar con dos o más tipos de laboratorios  Permite incluir control de versiones y monitorización  Los ESB de diferentes universidades u organizaciones ofrecen una pasarela externa para comunicarse entre ellos
  82. 82. CAPA DE COMUNICACIÓN LMS Cliente REST Servidor Laboratorio 1 Servidor Laboratorio 2 E S B WS REST WS SOAP Adaptador Adaptador Servicio de reserva WS REST 1. Petición del servicio acceso laboratorio 2 2.Comprobar reserva3.O k o N O 4. Acceso ok. Entonces pedir accesoAdaptador 5. Información de acceso 6. Información de acceso
  83. 83. ÍNDICE  Introducción  Situación Actual  Proyecto iLab (MIT)  Arquitectura Propuesta  Trabajos Realizados  Desarrollos realizados y utilización  Trabajos Futuros  Conclusión
  84. 84. TRABAJOS REALIZADOS  Primer paso es crear un servicio o herramienta dentro de los LMS de tal forma que sea posible gestionar laboratorios dentro del LMS. Actualmente:  Creado un paquete dotLRN  Creado un módulo en Moodle V1  Insertar laboratorios en WebCT
  85. 85. TRABAJOS REALIZADOS  Paquete dotLRN Sistemas operativos (Windows, Solaris, Linux,BSD) Base de datos (PostgreSQL, Oracle) AOLserver (TCL) Servicios de la plataforma Desarrollo de software (gestión de paquetes , plantillas, etc.) Orientación a Objetos Seguridad (Permisos OpenACS, restricciones de página , etc) Servicios de Aplicaciones (Repositorio de contenidos , Servicios Web, etc.) Modulo de Aplicaciones Standards (IMS, SCORM) Administración de Cursos (Calendario, Evaluación, Seguimiento de usuarios ) Contenidos (gestión de contenidos , Área de almacenamiento , etc.) Collaboration (forums, chats) Otros (e-commerce) Entorno laboratorio
  86. 86. TRABAJOS REALIZADOS packages root Nombre del paquete Nombre del paquete.info Fichero de especificación del paquete en XML donde se indica el nombre, propietario, url, etc. sql oracle Nombre del paquete-create.sql Nombre del paquete-drop.sql *.sql Script de creación del modelo de datos del paquete para Oracle Script de borrado del modelo de datos del paquete para Oracle Ficheros del modelo de datos updates Contiene los ficheros para actualizar el modelo de datos (nuevas versiones) postgresql Tiene la misma estructura que el directorio Oracle. Pero para Postgresql tcl Modelo de datos del paquete Contiene la lógica del paquete *-oracle.xql *-postgresql.xql Ficheros con consultas específicas de Oracle. El nombre del fichero, debe coincidir con el nombre del fichero TCL que utiliza dichas consultas Ficheros con consultas específicas de Postgresql. El nombre del fichero, debe coincidir con el nombre del fichero TCL que utiliza dichas consultas Nombre del paquete-procs.tcl Proporciona una API para el paquete Nombre del paquete-init.tcl Proporciona los procedimientos TCL que se ejecutarán una única vez al iniciar el servidor lib Contiene ficheros TCL y ADP que pueden ser incluidos en otros ficheros www Interfaz de usuario, documentación, pruebas para el comprobar el funcionamiento del paquete, etc. doc Contiene una serie de ficheros y directorios para crear la interfaz de usuario y probar que el paquete funciona correctamente. admin Documentación del paquete resources Ficheros de contenido estático Ficheros tcl, adp, xql Para la creación del interfaz de usuario Otros paquetes
  87. 87. TRABAJOS REALIZADOS
  88. 88. TRABAJOS REALIZADOS  Creación del paquete 1. Crear un paquete vacio 2. Base de datos postgreSQL
  89. 89. TRABAJOS REALIZADOS 3. Configuración del portal del grupo laboratorio. En este paso de deben definir las páginas y herramientas que van a formar parte de dicho portal 4. Procedimientos que se lanzan en la instalación, instanciación actualización y montaje del paquete 5. Modificación de archivos ya existente y de portlets de grupo
  90. 90. TRABAJOS REALIZADOS  Cómo resultado de modificar los archivos
  91. 91. TRABAJOS REALIZADOS  Crear una interfaz de administrador Tipo Laboratorios Gestionar tipos laboratorios Tipos de acceso a laboratorios Gestionar tipos acceso laboratorios LaboratoriosGestionar laboratorios Grupos Gestionar grupos Administrador A) B) C) D) I.U.
  92. 92. TRABAJOS REALIZADOS  Crear portlet de administración del grupo laboratorios Administrador del grupo I.U Gestionar herramientas Herramientas Laboratorios Añadir Deshabilitar Situar en el portal Gestionar laboratorios Asociar Quitar
  93. 93. TRABAJOS REALIZADOS  Crear portlet de usurio del grupo laboratorios Miembro del grupo I.U Mostrar laboratorios grupos Acceso a laboratorios Laboratorios
  94. 94. TRABAJOS REALIZADOS  Crear un applet que es el encargado de:  Definir las propiedades (la página del portal en la que se visualizará el portlet, el estado (oculto, minimizado, etc.)  La ordenación dentro de la página
  95. 95. TRABAJOS REALIZADOS
  96. 96. TRABAJOS REALIZADOS
  97. 97. TRABAJOS REALIZADOS Profesor del Curso
  98. 98. TRABAJOS REALIZADOS Alumno del Curso
  99. 99. TRABAJOS REALIZADOS Alumno del Curso
  100. 100. TRABAJOS REALIZADOS  Modulo de Acrividad Moodle (Mysql, Apache, php) mod moodle nombremodulo db install.xml upgrade.php access.php esquema de la base de datos en xmldb. Este fichero se utiliza cuando se instala el modulo en Moodle. Define los cambios en el esquema de la base de datos. Se ejecuta cuando se actualiza el módulo Contiene las capacidades (permisos del módulo) Icono gráfico que se asocia al móduloicon.gif Módulo que vamos a crear Otros módulos Contiene información sobre la versión del móduloversion.php Muestra la lista de instancias de actividades del módulo que hay en el curso. index.php Funciones requeridas por Moodle para comunicarse con este módulo.lib.php Muestra una instancia particular de la actividadview.php Formulario para configurar o actualizar una instancia de esta actividadmod_form.php Funciones para realizar las copias de seguridad del módulobackuplib.php Funciones para restablecer una copia de seguridad del módulorestorelib.php Página de administrador del módulo (opcional)settings.php o settingstree.php lang Contiene los ficheros de idiomas para esa actividad otros Otros directorios creados por el programador del módulo otros ficheros.php Otros ficheros específicos de este módulo y creados por el programador
  101. 101. TRABAJOS REALIZADOS  Crear un directorio dentro de la carpeta moodle/mod con el nombre del módulo a desarrollar, en nuestro caso, lo hemos llamado wlab. Para:  Creación de la base de datos utilizada por el módulo, lógica de negocio e interfaces de usuario  Definir las tablas del módulo wlabs  Capa de abstracción de base de datos para evitar tener trabajar, de forma directa, con código para Oracle o MySQL. Los pasos a realizar son >>>>>>>
  102. 102. TRABAJOS REALIZADOS  Crear la lógica del módulo  Crear el fichero mod.html. Este fichero, es un formulario utilizado desde course/mod.php y aparece cuando el administrador del curso pretende añadir o editar una instancia de un laboratorio en un curso. El formulario, por tanto, mostrará los campos a rellenar para crear o editar una instancia del módulo dentro de un curso  Crear el fichero lib.php. Es la librería del módulo, se encuentran todas las funciones que va a necesitar el módulo u otros módulos que quieran realizar operaciones sobre él  Crear el fichero view.php. Este fichero muestra todas las instancias de los laboratorios en un curso  Crear el fichero versión.php. Donde se indica información del paquete  Al igual que en dotLRN (view.tcl), existe un fichero view.php encargado de gestionar el acceso a los laboratorios
  103. 103. TRABAJOS REALIZADOS  El módulo de actividad creado para laboratorios permite:  crear, modificar y borrar instancias de ellos dentro de los cursos de dotLRN  Para realizar estas operaciones es necesario que antes el administrador de Moodle incluya toda la información de los laboratorios disponibles en el LMS Modificado el bloque de Administración de Moodle
  104. 104. TRABAJOS REALIZADOS
  105. 105. TRABAJOS REALIZADOS Administrador
  106. 106. TRABAJOS REALIZADOS Profesor del curso
  107. 107. TRABAJOS REALIZADOS Profesor del curso
  108. 108. TRABAJOS REALIZADOS Alumno del curso
  109. 109. TRABAJOS REALIZADOS Alumno del curso
  110. 110. TRABAJOS REALIZADOS  WebCT  Los profesores deben crear la categoría laboratorio y sus páginas web de acceso al laboratorio para cada curso  En el caso de que se necesite autenticación (los datos de esta, deben estar en las páginas de programación)  En muchas ocasiones las instituciones no dejan que cualquier persona que no sea un programador pueda incluir páginas con programación. Problemas de seguridad  No se crea una base de datos para almacenar laboratorios y experimentos. En el momento que cambié algún dato como la URL. Todas las páginas que contengan ese laboratorio deben modificarse una a una
  111. 111. TRABAJOS REALIZADOS Profesor del Curso
  112. 112. TRABAJOS REALIZADOS Profesor del Curso y Alumno
  113. 113. TRABAJOS REALIZADOS Alumno del Curso
  114. 114. TRABAJOS REALIZADOS (SCORM)
  115. 115. ÍNDICE  Introducción  Situación Actual  Proyecto iLab (MIT)  Arquitectura Propuesta  Trabajos Realizados  Trabajos Futuros  Conclusión
  116. 116. TRABAJOS FUTUROS  Creación de módulos de otros LMS de código abierto  aLF y Utilización de Laboratorios  Desarrollo de la arquitectura de comunicación LMS y laboratorios  Global Online Laboratory Consortium
  117. 117. TRABAJOS FUTUROS  Sloodle y el módulo de gestión de laboratorios  Creación e implantación de nuevos laboratorios en el DIEEC
  118. 118. ÍNDICE  Introducción  Situación Actual  Proyecto iLab (MIT)  Arquitectura Propuesta  Trabajos Realizados  Trabajos Futuros  Conclusión
  119. 119. CONCLUSIONES  Reutilización de Servicios de LMS  Reutilización de estándares e-learning  Propuesta una arquitectura global para la unión de LMS y Laboratorios  Buscar nuevas vías de estándares para: • Búsqueda de laboratorios • Utilización de laboratorios desde distintas plataformas
  120. 120. CONCLUSIONES Situación actual Situación después de aplicar la arquitectura planteada LMS Laboratorio Autenticación Base de Datos Logs Grupos y Gestión de Perfiles Seguridad Herramientas de Evaluación (IMS-QTI…) Herramientas de Grupo Contenidos (SCORM, IMS…) Interfaz de Usuario Servicio de reservas Gestión de Logs de Experimentos Autenticación básica Herramientas de Comunicación LMS Laboratorio Autenticación Base de Datos Logs Grupos y Gestión de Perfiles Seguridad Herramientas de Evaluación (IMS-QTI…) Herramientas de Grupo Contenidos (SCORM, IMS…) Interfaz de Usuario Servicio de reservas Gestión de Logs de Experimentos Autenticación Grupos y Gestión de Perfiles Contenidos (No SCORM…) Herramientas de Comunicación Herramientas de Comunicación Herramientas de Evaluación
  121. 121. GRACIAS POR SU ATENCIÓN Manuel-Alonso Castro Gil y Elio San Cristóbal Ruiz Departamento de Ingeniería Eléctrica, Electrónica y de Control (UNED) (mcastro@ieec.uned.es y elio@ieec.uned.es)
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×