2010-12-10 (uc3m) emadrid jcvidal usc integracion de ims ld en mundos virtuales
DESCRIPTION
2010-12-10 (uc3m) eMadrid Juan Carlos Vidal Aguiar Universidad de Santiago de Compostela Integración de IMS LD en mundos virtualesTRANSCRIPT
Integración de IMS LD en
mundos virtualesJuan Carlos Vidal Aguiar
Universidad de Santiago de Compostela
Red eMadrid, www.emadridnet.org
Universidad Carlos III de Madrid (Madrid), 10 de Diciembre de 2010
Mundos virtuales 3D
Metaversos o mundos virtuales 3D son entornos gráficos
tridimensionales, multiusuarios, inmersivos e interactivos
generados por computadoras en tiempo real
Principales características
Las principales características de los mundos virtuales 3D
son la corporeidad, la interactividad, y la persistencia
Corporeidad
• El mundo virtual se compone
de elementos físicos 3D cuya
dinámica está gobernada por
leyes físicas del mundo real
• Los usuarios se identifican con
un avatar que es su alter ego
en el mundo virtual 3D
• Cualquier acción que toma el usuario como siempre tiene lugar a través del
avatar con el que se identifica el usuario
Principales características
Las principales características de los mundos virtuales 3D
son la corporeidad, la interactividad, y la persistencia
Interactividad
• Los avatares interaccionan con el mundo
virtual para obtener/generar información o para
modificar los elementos de los que se compone
• Los avatares interaccionan con los otros
avatares del mundo virtual para socializar
(como sucede en el mundo real)
• Uso de herramientas de comunicación
para facilitar la interacción entre los usuarios
(chat, audioconferencia, …)
Principales características
Las principales características de los mundos virtuales 3D
son la corporeidad, la interactividad, y la persistencia
Persistencia
• El mundo virtual 3D sigue
evolucionando independientemente de
que el usuario esté o no esté conectado
• El estado del avatar se mantiene
entre sesiones consecutivas; es decir,
se recuerda el resultado de las
acciones realizadas por el avatar
• Esta característica es un reflejo de lo que sucede en el mundo real:
el entorno del avatar puede evolucionar aún cuando no esté presente
Entornos docentes virtuales 3D
Las características de los mundos virtuales 3D son muy
deseables cuando se aplican a la Educación en los
llamados entornos docentes virtuales 3D
Favorecen la inmersión de los estudiantes en el entorno docente
3D virtual, lo que aumenta su nivel de implicación en la
realización de las actividades docentes
Favorecen la interacción y comunicación entre todos los que
participan en las actividades de aprendizaje
(estudiante estudiante, estudiantes profesor)
Permiten una gran variedad de estilos de aprendizaje, y en
especial favorecen el aprendizaje colaborativo
Entornos docentes virtuales 3D
Pizarra Virtual Mundo virtual 3D
Interacción Los usuarios expresan sus ideas
de modo colaborativo en la
pizarra virtual de forma
colaborativa
Los usuarios expresan sus ideas
de forma colaborativa en un
elemento físico del entorno
docente
Persistencia El contenido de la pizarra
virtual cambia entre
conexiones consecutivas del
usuario
El contenido de la pizarra
cambia entre conexiones
consecutivas del usuario
Corporeidad Los usuarios de una pizarra
virtual no son corpóreos
Los avatares y el entorno
docente dan la sensación de
corporeidad y de inmersión en
el entorno virtual
En los últimos años empresas y universidades han
desarrollado un buen número de entornos docentes
virtuales 3D
Se crean sofisticados y muy elaborados campus de docencia para
aumentar la sensación de inmersión en el mundo virtual por parte
de los estudiantes
Campus virtual en 3D en el que
se incluyen elementos físicos
paisajísticos
Entornos docentes virtuales 3D
Aulas docentes con proyectores y pizarras
virtuales
Salas de socialización
Edificios administrativos y bibliotecas
La mera réplica de campus reales a campus virtuales 3D no es
suficiente para mejorar el aprendizaje: es necesario aplicar técnicas
docentes basadas en las interacciones y la colaboración entre
estudiantes
Entornos docentes virtuales 3D
Existe muy poca investigación y experimentación en este punto:
La mayoría de propuestas centradas en el ámbito de los juegos
(ejemplo: <e-Adventure>)
Arquitectura software no es lo suficientemente flexible como para
generalizar la solución a otras plataformas
Las soluciones son fuertemente dependientes del entorno docente
virtual 3D que se ha definido
¿Cómo aplicar las técnicas
docentes en los mundos virtuales?
Se han desarrollado una serie de plataformas de mundos virtuales de
propósito general:
De las cuales Opensim y Second Life han sido de largo las más usadas
en el ámbito educativo.
Plataformas de mundos virtuales
Opensim
Second Life
Open Wonderland
Open Cobalt
Plataformas de mundos virtuales
Second Life Opensim
Lenguaje de
scripts
LSL (Linden Script Language) LSL + extensiones
Código
abierto
No
(propiedad de Linden Labs)
Sí
Lenguaje de
desarrollo
C# C#
(permite añadir nuevos módulos
en C# y en Php)
Second Life y Opensim utilizan LSL como el lenguaje de scripts con el
que se da tratamiento a los eventos que los avatares generan en el
mundo virtual.
¿Por qué no aprovechar los
cursos ya creados?
Un Lenguaje de Modelado Educativo (EML) describe el flujo de
actividades de aprendizaje a realizar por los estudiantes y profesores,
con el fin de alcanzar unos objetivos educativos, y utilizando el material
educativo proporcionado.
IMS Learning Design (IMS LD)
ha surgido como el estándar de
facto dentro de los EML debido
a su alto nivel de consenso y su
soporte tecnológico
Aprendizaje adaptativo
Define un esquema de control complejo.
Utiliza el formato XML Schema para especificar las unidades de aprendizaje.
Es necesario un intérprete para automatizar la ejecución de los flujos de trabajo
de IMS LD.
En nuestro desarrollo utilizamos OPENET4LD, un motor de flujos de trabajo que
implementa las unidades de aprendizaje IMS LD.
NUESTRA
ELECCIÓN
E-learningColaboración + aprendizaje
Educación + entorno social
Digital media that enable socialization + aprendizaje
EDUCACIÓN +
MUNDOS 3D
EML / IMS-LD
+ INTERNET
EML / IMS-LD +
MUNDOS 3D
Por ejemplo:
Moodle + Second Life,
enfocados a los contenidos
y no en la ejecución
No existe un motor de
ejecución para desarrollar
y soportar el curso
Herramientas de
comunicación
Síncrona: chat
Asíncrona: correo,
foros, etc.
El control de definido en IMS LD se diseña/replica
directamente en la plataforma de metaversos
Primera opción de integración
El control está distribuido entre los elementos físicos del escenario
y programado con el lenguaje de scripting, específico de cada
plataforma de metaversos.
Problemas:
El lenguaje de scripting debe soportar la definición de
estructuras de datos complejas.
El motor tiene una fuerte dependencia con el escenario virtual
educativo.
El motor IMS LD se implementa como un
módulo software de la plataforma de metaversos
Segunda opción de integración
Problemas:
El motor depende de la implementación de la plataforma de
metaversos, sus interfaces y sus componentes software.
Esta solución es válida sólo para Opensim, ya que esta
plataforma tiene una arquitectura abierta y extensible a través
de pluggins.
Integración basada en las comunicaciones:
El motor IMS LD está fuera de la plataforma de metaversos
Tercera opción de integración
Beneficios:
Se simplifica el diseño de los scripts que quedan reducidos a
llamadas al motor IMS LD.
La solución es más portable a otras plataformas. El flujo de trabajo
definido en el motor IMS LD no cambia, de forma que únicamente se
necesitaría (re)implementar los scripts.
Se utiliza el protocolo HTTP y RPC para comunicarse con el motor,
el cual devuelve los resultados como cadenas de texto (URL,
identificadores de actividades, etc.).
NUESTRA
ELECCIÓN
Marco conceptual de integración
Identificar los elementos de los que se componen los
entornos docentes virtuales 3D que intervienen en la
ejecución de unidades de aprendizaje IMS LD
Componentes físicos del entorno docente virtual 3D
Avatares que juegan los roles de
estudiantes y de profesores
Scripts que gestionan los eventos generados en el
mundo virtual 3D
Motor IMS LD que gestiona la correcta ejecución de
la unidad de aprendizaje adaptativa
Marco conceptual de integración
Los elementos físicos del
entorno docente tienen
ligados scripts cuya
invocación tiene ante la
ocurrencia de un evento
Los scripts invocan a los
servicios del motor de
ejecución encargados de
realizar la adaptación de
la unidad de aprendizaje
El avatar interacciona
con los elementos físicos
del entorno virtual
generando eventos que
deberán ser tratados por
el sistema
Los avatares no tienen
interacción directa con
el motor IMS LD: debe
establecerse a través de
un elemento físico 3D
¿Cómo se integran los mundos
virtuales con los motores IMS LD?
Nuestra solución implica el diseño de una
arquitectura distribuida de cara a facilitar el acceso
de la plataforma de metaversos a las funcionalidades
del motor IMS LD.
Analizamos dos opciones:
Arquitectura basada en agentes.
Arquitectura orientada a servicios.
¿Arquitectura orientada a
servicios?
Beneficios:
Permite la reutilización de la arquitectura en otras plataformas de
metaverso.
Adición de nuevas funcionalidades sin cambiar los scripts ni los
servicios.
Las funcionalidades del motor están externalizadas
a través de servicios web y proporcionan acceso:
Al estado y ejecución de los flujos de trabajo IMS LD.
A los contenidos y recursos educativos de las unidades de aprendizaje.
NUESTRA
ELECCIÓN
Arquitectura orientada a servicios
HTTP BC
JMS BC
File BC
FTP BC
JDBC BC
MQ BC
SMTP BC
UDDI BC
BPEL SE
XSLT SE
SQL SE
IEP SE
Metaverse
Requests
Management
(MRM)
JAXWSM
MR
(JB
I B
us)
Sun Java System Application Server 9.1
JBI Runtime
Environment OPENET4LD
User
Management
PNDefinition
UoL
Publication
UoLState
Management
PNState
Management
UoL
Execution
PN
ExecutionIMSLD2PN
UoL2FLORAUoL
Validation
Web Services
CAPA SERVIDOR CAPA DE SERVICIOSCAPA CLIENTE
Op
en
Sim
/Se
co
nd
Lif
e V
iew
er
Op
en
Sim
/Se
co
nd
Lif
e S
erv
er
Arquitectura orientada a servicios
HTTP BC
JMS BC
File BC
FTP BC
JDBC BC
MQ BC
SMTP BC
UDDI BC
BPEL SE
XSLT SE
SQL SE
IEP SE
Metaverse
Requests
Management
(MRM)
JAXWSM
MR
(JB
I B
us)
Sun Java System Application Server 9.1
JBI Runtime
Environment OPENET4LD
User
Management
PNDefinition
UoL
Publication
UoLState
Management
PNState
Management
UoL
Execution
PN
ExecutionIMSLD2PN
UoL2FLORAUoL
Validation
Web Services
CAPA SERVIDOR CAPA DE SERVICIOSCAPA CLIENTE
Op
en
Sim
/Se
co
nd
Lif
e V
iew
er
Op
en
Sim
/Se
co
nd
Lif
e S
erv
er
La capa cliente se
encarga de ejecutar
los scripts invocados
por las acciones de los
clientes
Arquitectura orientada a servicios
HTTP BC
JMS BC
File BC
FTP BC
JDBC BC
MQ BC
SMTP BC
UDDI BC
BPEL SE
XSLT SE
SQL SE
IEP SE
Metaverse
Requests
Management
(MRM)
JAXWSM
MR
(JB
I B
us)
Sun Java System Application Server 9.1
JBI Runtime
Environment OPENET4LD
User
Management
PNDefinition
UoL
Publication
UoLState
Management
PNState
Management
UoL
Execution
PN
ExecutionIMSLD2PN
UoL2FLORAUoL
Validation
Web Services
CAPA SERVIDOR CAPA DE SERVICIOSCAPA CLIENTE
Op
en
Sim
/Se
co
nd
Lif
e V
iew
er
Op
en
Sim
/Se
co
nd
Lif
e S
erv
er
La capa servidor dispone
de un módulo para la
invocación de servicios
disparados por los
scripts de la plataforma
de metaversos.
Arquitectura orientada a servicios
HTTP BC
JMS BC
File BC
FTP BC
JDBC BC
MQ BC
SMTP BC
UDDI BC
BPEL SE
XSLT SE
SQL SE
IEP SE
Metaverse
Requests
Management
(MRM)
JAXWSM
MR
(JB
I B
us)
Sun Java System Application Server 9.1
JBI Runtime
Environment OPENET4LD
User
Management
PNDefinition
UoL
Publication
UoLState
Management
PNState
Management
UoL
Execution
PN
ExecutionIMSLD2PN
UoL2FLORAUoL
Validation
Web Services
CAPA SERVIDOR CAPA DE SERVICIOSCAPA CLIENTE
Op
en
Sim
/Se
co
nd
Lif
e V
iew
er
Op
en
Sim
/Se
co
nd
Lif
e S
erv
er
La capa de servicios
publica las funcionalidades
del motor y resuelve las
consultas a las unidades
de aprendizaje.
Escenario docente
Pantalla
Facilita la visualización del
contenido educativo (como
vídeos o presentaciones)
asociado a las actividades de
las unidades de aprendizaje
que están ejecutando en ese
momento.
Panel de selección
Facilita la interacción de los avatares con el motor IMS LD, de forma
que pueden buscar información acerca de una determinada unidad
de aprendizaje y obtener la(s) siguiente(s) actividad(es) a realizar.
Pantalla y modos de operación
2. El avatar visualiza el contenido de forma individual.
Los estudiantes usan la pantalla para desplegar los recursos
educativos asociados a la actividad que están realizando.
1. Todos los avatares visualizan
el mismo contenido.
Los profesores aplican esta
estrategia para explicar el
contenido a los alumnos.
Panel de selección
En panel de notas
(notecard) muestra
la información
relativa a la actual
unidad de
aprendizaje.
Cuando el avatar toca
esta parte del panel,
se invoca el servicio
web encargado de
obtener la información
y objetivos de la
actividad que está
realizando.
Cuando el avatar
toca esta parte del
panel, se invoca el
servicio web
encargado de
obtener los
recursos asociados
con la unidad de
aprendizaje.
Cuando el avatar
toca esta parte del
panel, se invoca el
servicio web que
finaliza la actividad
actual. Como
resultado, se
muestra al avatar la
siguiente actividad a
realizar.
Capa cliente: scripts
1. Vídeos
2. Imágenes
3. Presentaciones
Arquitectura orientada a servicios
HTTP BC
JMS BC
File BC
FTP BC
JDBC BC
MQ BC
SMTP BC
UDDI BC
BPEL SE
XSLT SE
SQL SE
IEP SE
Metaverse
Requests
Management
(MRM)
JAXWSM
MR
(JB
I B
us)
Sun Java System Application Server 9.1
JBI Runtime
Environment OPENET4LD
User
Management
PNDefinition
UoL
Publication
UoLState
Management
PNState
Management
UoL
Execution
PN
ExecutionIMSLD2PN
UoL2FLORAUoL
Validation
Web Services
CAPA SERVIDOR CAPA DE SERVICIOSCAPA CLIENTE
Op
en
Sim
/Se
co
nd
Lif
e V
iew
er
Op
en
Sim
/Se
co
nd
Lif
e S
erv
er
HTTP BC
JMS BC
File BC
FTP BC
JDBC BC
MQ BC
SMTP BC
UDDI BC
BPEL SE
XSLT SE
SQL SE
IEP SE
Metaverse
Requests
Management
(MRM)
JAXWS
MM
R (
JB
I B
us)
Sun Java System Application Server 9.1
JBI Runtime
Environment
BC: Binding Component
SE: Service Engine
Gestión de peticiones del servidor
Módulo de gestión de peticiones de
los metaversos (Metaverse Requests
Management - MRM):
Se compone de un conjunto de servlets
Los servlets recogen directamente las
peticiones de los scripts (a través de la
función HTTPRequest, y ejecutan el
método GET como consecuencia de
esas peticiones) y redirige las
peticiones al correspondiente servicio
web del motor IMS LD
Un Servidor de Aplicaciones da
soporte al despliegue e invocación
de los servicios Web.
HTTP BC
JMS BC
File BC
FTP BC
JDBC BC
MQ BC
SMTP BC
UDDI BC
BPEL SE
XSLT SE
SQL SE
IEP SE
Metaverse
Requests
Management
(MRM)
JAXWS
MM
R (
JB
I B
us)
Sun Java System Application Server 9.1
JBI Runtime
Environment
BC: Binding Component
SE: Service Engine
Gestión de peticiones del servidor
Módulo de gestión de peticiones de
los metaversos (Metaverse Requests
Management - MRM):
Se compone de un conjunto de servlets
Los servlets recogen directamente las
peticiones de los scripts (a través de la
función HTTPRequest, y ejecutan el
método GET como consecuencia de
esas peticiones) y redirige las
peticiones al correspondiente servicio
web del motor IMS LD
Un Servidor de Aplicaciones da
soporte al despliegue e invocación
de los servicios Web.
La necesidad de este módulo está impuesta por las limitaciones del lenguaje
de scripts.
Arquitectura orientada a servicios
HTTP BC
JMS BC
File BC
FTP BC
JDBC BC
MQ BC
SMTP BC
UDDI BC
BPEL SE
XSLT SE
SQL SE
IEP SE
Metaverse
Requests
Management
(MRM)
JAXWSM
MR
(JB
I B
us)
Sun Java System Application Server 9.1
JBI Runtime
Environment OPENET4LD
User
Management
PNDefinition
UoL
Publication
UoLState
Management
PNState
Management
UoL
Execution
PN
ExecutionIMSLD2PN
UoL2FLORAUoL
Validation
Web Services
CAPA SERVIDOR CAPA DE SERVICIOSCAPA CLIENTE
Op
en
Sim
/Se
co
nd
Lif
e V
iew
er
Op
en
Sim
/Se
co
nd
Lif
e S
erv
er
Arquitectura del motor IMS LD
FLORA-2 Reasoner
Inference Engine
Base de conocimiento
Schema
HLPN
Ontology
Data
HLPN
Instances
Rules
HLPN
Reasoning
IMS LD Engine
Reasoner Interface
HLPN engine interface HHLPN engine interface
OPENET Engine
IMS LD engine interfaceOPENET engine interface
Schema
HHLPN
Ontology
Data
HHLPN
Instances
Rules
HHLPN
Reasoning
MAPPINGS
MAPPINGS
Schema
OPENET
Ontology
Data
OPENET
Instances
Rules
OPENET
Reasoning
MAPPINGS
MAPPINGS
Schema
IMS LD
Ontology
Data
IMS LD
Instances
Rules
IMS LD
Reasoning
MAPPINGS
MAPPINGS
Arquitectura del motor IMS LD
FLORA-2 Reasoner
Inference Engine
Base de conocimiento
Schema
HLPN
Ontology
Data
HLPN
Instances
Rules
HLPN
Reasoning
IMS LD Engine
Reasoner Interface
HLPN engine interface HHLPN engine interface
OPENET Engine
IMS LD engine interfaceOPENET engine interface
Schema
HHLPN
Ontology
Data
HHLPN
Instances
Rules
HHLPN
Reasoning
MAPPINGS
MAPPINGS
Schema
OPENET
Ontology
Data
OPENET
Instances
Rules
OPENET
Reasoning
MAPPINGS
MAPPINGS
Schema
IMS LD
Ontology
Data
IMS LD
Instances
Rules
IMS LD
Reasoning
MAPPINGS
MAPPINGS
Estas tres capas
definen la semántica
de ejecución de los
flujos de trabajo. Esta
ejecución se basa en
el formalismo de las
redes de Petri.
Arquitectura del motor IMS LD
FLORA-2 Reasoner
Inference Engine
Base de conocimiento
Schema
HLPN
Ontology
Data
HLPN
Instances
Rules
HLPN
Reasoning
IMS LD Engine
Reasoner Interface
HLPN engine interface HHLPN engine interface
OPENET Engine
IMS LD engine interfaceOPENET engine interface
Schema
HHLPN
Ontology
Data
HHLPN
Instances
Rules
HHLPN
Reasoning
MAPPINGS
MAPPINGS
Schema
OPENET
Ontology
Data
OPENET
Instances
Rules
OPENET
Reasoning
MAPPINGS
MAPPINGS
Schema
IMS LD
Ontology
Data
IMS LD
Instances
Rules
IMS LD
Reasoning
MAPPINGS
MAPPINGS
Esta capa contiene la
ontología de IMS LD y el
conjunto de
transformaciones que
permiten definir un flujo de
trabajo a partir del modelo
IMS LD.
Arquitectura orientada a servicios
HTTP BC
JMS BC
File BC
FTP BC
JDBC BC
MQ BC
SMTP BC
UDDI BC
BPEL SE
XSLT SE
SQL SE
IEP SE
Metaverse
Requests
Management
(MRM)
JAXWSM
MR
(JB
I B
us)
Sun Java System Application Server 9.1
JBI Runtime
Environment OPENET4LD
User
Management
PNDefinition
UoL
Publication
UoLState
Management
PNState
Management
UoL
Execution
PN
ExecutionIMSLD2PN
UoL2FLORAUoL
Validation
Web Services
CAPA SERVIDOR CAPA DE SERVICIOSCAPA CLIENTE
Op
en
Sim
/Se
co
nd
Lif
e V
iew
er
Op
en
Sim
/Se
co
nd
Lif
e S
erv
er
OPENET4LD
User
Management
PNDefinition
UoL
Publication
UoLState
Management
PNState
Management
UoL
Execution
PN
ExecutionIMSLD2PN
UoL2FLORAUoL
Validation
Web Services
SERVICE LAYER
Esta capa se compone de un
conjunto de servicios que
externalizan las funcionalidades del
motor de IMS LD:
Publicar una UoL en el motor
Validar la estructura de una UoL
Iniciar la ejecución de una UoL
Gestionar los roles
Gestionar los usuarios
Servicios web del motor IMS LD
Más funcionalidades:
Gestionar la ejecución de una
UoL
Parar, suspender o reanudar la
ejecución de un método, play,
acto o actividad
Realizar una actividad
Acceder al estado de una
ejecución
Servicios web del motor IMS LD
RUNNINGPAUSED
FINISHED
run
SELECTED SELECTABLE
UNSTARTED
run select
enable
selection
finish / stop / halt/timeout /
when-property-value-is-set
selected activity
is finished
hierarchical
suspension
hierarchical
resume
SUSPENDED
suspend
resume
another activity
is selected
show
hide
DISABLED
Otras funcionalidades:
Transformar una UoL
a red de Petri
…
Servicios web del motor IMS LD
Los servicios están
descritos en WSDL y se
invocan a través de
mensajes SOAP.
Conclusiones
Las características de los mundos virtuales 3D son muy
deseables cuando se aplican a la Educación en los
llamados entornos docentes virtuales 3D:
Favorecen la inmersión de los estudiantes en el entorno docente
3D virtual, lo que aumenta su nivel de implicación en la
realización de las actividades docentes
Favorecen la interacción y comunicación entre todos los que
participan en las actividades de aprendizaje
(estudiante estudiante, estudiantes profesor)
Permiten una gran variedad de estilos de aprendizaje, y en
especial favorecen el aprendizaje colaborativo
Conclusiones
Hemos visto como a través de una arquitectura orientada a servicios
se facilita la ejecución, desde una plataforma de metaversos, de UoLs
basadas en el estándar IMS LD.
En esta arquitectura externaliza las funcionalidades del motor IMS LD
a través de servicios web de forma que terceras aplicaciones puedan
controlar la ejecución de las UoLs y los recursos educativos.
Las principales ventajas de esta aproximación son:
Reutilización de cursos previamente especificados en IMS LD
Reducir la complejidad de los scripts
La solución es “fácilmente” aplicable a otras plataformas de metaversos
Trabajos futuros
Mejorar el marco de integración en dos puntos:
Integrar más elementos físicos al entorno docente.
Reducir la complejidad del módulo usado para la gestión
de las peticiones desde la plataforma de metaversos.
Para ello se planeamos introducir la ejecución de estos
servicios web a través del lenguaje BPEL.