Teleprácticas: Sesiones Remotas vs. Acceso Remoto. Laboratorio de

prácticas libres ubicuo en la EPS Adolfo Albaladejo Blázquez, Antonio Francisco García Quintana

y Juan Antonio Gil Martínez-Abarca

Se expone el análisis, diseño e implementación de un sistema encriptado de sesiones remotas en un laboratorio permanente en el que los alumnos puedan realizar prácticas, independientemente de cuándo y dónde se encuentren y el hardware y el software necesarios. Los sistemas de acceso remoto existentes en la actualidad básicamente consisten en ofrecer una conexión a un ordenador cliente a una red remota utilizando diferentes niveles de seguridad. La tecnología de comunicaciones que se está imponiendo, gracias a su flexibilidad, escalabilidad, facilidad de configuración y bajo coste, son las denominadas VPNs o Redes Privadas Virtuales. El sistema de sesiones remotas propuesto constituye un marco independiente de la conexión del ordenador del usuario a Internet y proporciona un acceso encriptado a los recursos presentes en un laboratorio permanente, el cual es fácilmente extensible a otras aulas docentes, y para ello utiliza una aplicación segura a través de la web. Esto último hace que el sistema sea independiente de la plataforma hardware utilizada y también gracias a la enorme implantación de la World Wide Web hace que no sea necesario instalar ningún tipo de software para acceder al sistema, basta con disponer de un navegador web.

1 Introducción

Es indudable la importancia adquirida por las nuevas tecnologías de la información y comunicaciones (TIC) en todos los órdenes de la

sociedad y, en particular, en el ámbito de la Educación Superior donde han introducido nuevas formas de trabajo, relación e, incluso, cambios en los métodos pedagógicos con los que se superan los métodos tradicionales de difusión de la documentación por parte del profesor [1].

El objetivo, a la hora de aplicar las TIC en la docencia, consta de [1][2]:

• Proporcionar un escenario educativo nuevo caracterizado por la representación virtual del proceso de enseñanza (modelo centralizado en la enseñanza remota).

• Modelo que complementa la docencia presencial, sobre todo, como apoyo para el cumplimiento de las directrices marcadas por el Espacio Europeo de Educación Superior.

En España, universidades que apuesten por el primer modelo existen básicamente dos: Universidad Nacional de Educación a Distancia (UNED) y, en mayor medida, la Universitat Oberta de Catalunya (UOC). El resto de universidades está realizando un esfuerzo importante en el desarrollo de campus virtuales que complementen su docencia presencial, sin perder de vista la oferta de cursos on-line [3][4].

La universidad presencial actual se encuentra con que cada vez más, sus estudiantes poseen sus propios computadores (en casa o portátiles) con posibilidad de conexión en red (wireless, LAN o conexión residencial cada vez con mayor ancho de banda) y con la esperanza de que se conviertan en una herramienta útil en su preparación universitaria a todos los niveles, incluso en la docencia práctica.

Como señalan diversos autores [5][6], ya es un componente de excelencia universitaria el disponer de una infraestructura tecnológica que permiten transformar los equipos propietarios de los estudiantes en potenciales clientes de laboratorios y aulas informáticas (incluso en aulas de teoría) que puedan utilizar los recursos hardware y software de la Universidad conectándose desde cualquier punto del campus o, en general, desde Internet.

Si, por otra parte, se tiene en cuenta que la formación de los alumnos universitarios en TIC ha aumentado progresivamente en los últimos años [7] se justifica sobradamente el apoyo que la mayor parte de las universidades españolas está dando a la docencia virtual por Internet [4] en sus distintos modelos.

Existen múltiples universidades que utilizan la red y sus servicios para proporcionar información (directorio de profesores, alumnos y personal de administración y servicios), tareas de administración universitaria, calificaciones, etc. Sin embargo, estas acciones, si bien sirven de apoyo a la docencia, no utilizan las capacidades de las TIC para proporcionar un nuevo espacio para desarrollar actividades educativas [1].

La expansión de la disponibilidad del material educativo implica el desarrollo de recursos que puedan estar online —presentaciones de los profesores, materiales de investigación, datos, herramientas de análisis, programas multimedia y otras herramientas basadas en web— y accesibles desde todos los lugares de estudio incluyendo las propias redes inalámbricas desde cualquier punto del campus [8].

Para mejorar las comunicaciones tanto dentro como más allá del campus, estas redes soportan websites institucionales de departamentos, grupos de investigación y asignaturas. Los estudiantes y docentes utilizan nuevos medios de comunicación como el e-mail, chats u otros formatos online. Los docentes disponen de información relativa a la docencia como calificaciones o informes de forma electrónica en lugar de procesarla y almacenarla sobre papel.

Sin embargo, un aspecto importante que se encuentran los alumnos durante su formación práctica, sobre todo en las titulaciones técnicas y experimentales, es la falta de disponibilidad y coste del software y el hardware necesario para realizarlas. En la actualidad, una institución educativa como la Escuela Politécnica Superior (EPS) de la Universidad de Alicante (UA) dispone de una infraestructura tanto de software como hardware en los laboratorios así como de comunicaciones que, aunque se puede mejorar para dar más servicios, también se puede

utilizar de forma más eficiente [9][10]. A continuación enumeramos una serie de casos típicos que cumplirían este segundo punto:

• La infrautilización de los equipos y de las licencias de software adquiridas debido a que los laboratorios de la EPS tienen un calendario y un horario de apertura fijado que restringe su utilización a las sesiones presenciales de prácticas. Durante el resto del tiempo, tanto en días como en horas no lectivas, estos recursos no están disponibles ni para el profesorado ni para el alumnado.

• La revisión remota por parte del profesorado de las instalaciones realizadas por los técnicos de la EPS en los laboratorios.

• La infrautilización de los recursos más escasos de la EPS debido a su elevado precio, puestos de edición de vídeo, ...

En el presente capítulo se presenta un laboratorio virtual de acceso remoto para la realización de prácticas con ordenador, basado en tecnologías web.

2 Estado actual

En la actualidad existen varias iniciativas que, en una línea similar a la descrita, utilizan diversos recursos basados en las tecnologías de la información para el apoyo a la enseñanza.

Para la docencia teórica existe cada vez más trabajo desarrollado habitualmente como cursos on-line y/o apoyo a cursos presenciales o semi-presenciales, no estando tan extendido para el caso de la docencia práctica (aspecto de suma importancia sobre todo en las carreras técnicas y experimentales donde puede suponer hasta el 50% de la docencia). En principio, se suele considerar que la docencia práctica ha de ser principalmente presencial, sin embargo, debido a las razones expuestas anteriormente se vislumbra la necesidad del apoyo que se puede ofrecer con las nuevas tecnologías.

En Internet podemos encontrar multitud de recopilaciones de recursos existentes según las diferentes materias como, por ejemplo, en [11] donde además se realiza una clasificación de diferentes tipos de laboratorios según sean remotos, monolíticos, distribuidos o híbridos.

Dentro de estos denominados laboratorios remotos también encontramos otras experiencias basadas en diferentes sistemas de comunicaciones como, por poner algunos ejemplos:

• Java SSH (Secure Shell) [12] [13] [14].

• VNC – Virtual Network Computing (sobre protocolo RFB, Remote FrameBuffer) con SSH [15].

• Terminal Server (sobre protocolo RDP, Remote Desktop Protocol) [16].

Un inconveniente común a estos sistemas es que todos ellos basan su funcionamiento en una aplicación software servidor que es necesario que esté en funcionamiento en el propio ordenador del laboratorio remoto. Esto puede implicar una serie de dificultades como sería sencillamente la corrupción de dicha aplicación software servidor debido a la interacción del usuario con el ordenador del laboratorio remoto (por ejemplo, debido a cambios de configuración del direccionamiento IP o a la manipulación de los parámetros de configuración de la propia aplicación) con la consiguiente caída del sistema.

Por otro lado, todos los sistemas mencionados anteriormente también precisan para su funcionamiento de un sistema operativo, más o menos específico según cada uno de ellos, por lo que hasta que éste termine de arrancar y cargue la aplicación software servidor mencionada no se podrá ofrecer el acceso.

Además de estas características comunes, cada uno analizado por separado presenta unos problemas específicos relacionados con la seguridad, el rendimiento, la portabilidad, etc., que dejaban muchas cuestiones sin resolver.

3 Propuesta

3.1 Laboratorio ubicuo

El Laboratorio Ubicuo consiste en una aplicación basada en tecnologías web clásicas con el que se pretende proporcionar sesiones remotas para que los alumnos puedan realizar prácticas basadas en ordenador independientemente de:

• dónde se encuentren,

• la hora y día que sea,

• hardware y software que necesiten.

Esta propuesta constituye un marco independiente de la conexión del ordenador del usuario a Internet y proporciona un acceso encriptado a los recursos presentes en un laboratorio permanente de la EPS, el cual es fácilmente extensible a otros usos y para ello utiliza una aplicación segura a través de la web. Esto último hace que el sistema sea independiente de la plataforma hardware utilizada y también gracias a la enorme implantación de la World Wide Web hace que no sea necesario instalar ningún tipo de software en el usuario para acceder al sistema, basta con disponer de un navegador web y, por la tecnología actualmente empleada, de un sistema operativo Windows.

En un principio, se proporcionan sesiones remotas a un ordenador del laboratorio permanente el cual tiene una configuración similar a la de un ordenador del laboratorio físico de la EPS en el cual el alumno realice sus prácticas presenciales.

Para ello, tras acceder al aula virtual mediante una conexión encriptada establecida con un navegador, el alumno debe seleccionar el PC en el que desea realizar sus prácticas y establecer la conexión a dicho ordenador, tal y como se indica en la Fig.1.

Tras la realización de estos pasos, el usuario dispone en su navegador de un ordenador con el escritorio del sistema operativo deseado.

Fig. 1. Casos de uso de la aplicación.

El sistema proporciona sesiones encriptadas mediante Secure Sockets Layer (SSL) con un ordenador completamente configurado con el hardware y software necesarios según las necesidades de cada usuario y que incluso puede estar o no conectado a la red de la EPS. Esto implica una serie de ventajas:

• La configuración del ordenador del laboratorio ha sido previamente comprobada y se ha asegurado su funcionamiento. No habrá más problemas de incompatibilidades, versiones diferentes de las aplicaciones y/o del sistema operativo o falta de recursos. Es más, esta configuración y personalización del ordenador puede llegar a ser tan específica como se desee, llegando al extremo de poder ser realizada y/o revisada a distancia por parte del mismo profesor, a partir de una base con el sistema operativo deseado.

• El ordenador del laboratorio está en un entorno completamente controlado (seguridad de red, antivirus,...) de forma local, al contrario de lo que sucede con el PC externo del usuario sobre el cual no se tiene ningún control.

• Se registrará la actividad generada durante la sesión.

• Las modificaciones realizadas en el ordenador se podrán descartar al desconectarse de la máquina volviéndose al estado inicial.

• El ordenador externo del usuario no dispone de ningún tipo de conexión de red con la EPS por lo que disminuye la posibilidad de cualquier comportamiento malicioso.

Efectivamente, el ordenador del laboratorio está conectado a la red de la EPS y, por lo tanto, tiene una conexión LAN Gigabit Ethernet con los servidores de la EPS y de la UA (webs de departamentos, espacio en disco, campus virtual, correo electrónico,...).

3.2 Tecnología

La aproximación de acceso al Laboratorio Ubicuo es radicalmente opuesta a la clásica solución de acceso remoto. Tradicionalmente, se proporciona acceso remoto a una red a ordenadores externos gestionados y en propiedad de los usuarios a través de una cuenta en el sistema de acceso remoto, creando un túnel desde el ordenador externo a través de Internet, asignándoles una dirección IP de la propia red local y controlando qué se les permite realizar mediante una política de seguridad determinada. Este sistema se basa en la confianza de que los propios usuarios velen por la seguridad de sus ordenadores y de la red a la que se han conectado, pero ¿qué ocurre cuando no es posible confiar así?

Hasta ahora la solución había consistido simplemente en denegar el acceso remoto a los usuarios no confiables.

3.2.1 Sesiones remotas

El problema de una comunicación segura entre ordenadores a través de una red que no lo es se resuelve normalmente con VPNs (Redes Privadas Virtuales) bien a nivel de enlace, a nivel de red o a nivel de aplicación. Cada una de estas tres alternativas tiene sus ventajas e inconvenientes:

• Las VPNs a nivel de enlace se implementan en los dispositivos que se conectan al medio de transmisión, por ejemplo, dos nodos que se comunican directamente mediante una línea punto a punto. Su uso es transparente para los protocolos utilizados a nivel de red y para su implementación se requiere controlar la infraestructura de la red. Por ejemplo, se utiliza en las redes de televisión por cable donde la información viaja encriptada entre el Cable Módem y el CMTS (Cable Modem Termination System) ya que al utilizar un medio broadcast es necesario el uso de encriptación para evitar la captación de información por parte de usuarios que no son los destinatarios de la misma.

• Las VPNs a nivel de red constituyen la opción implementada en los estándares IPsec. En este caso, la seguridad se limita al protocolo IP y los demás protocolos sólo podrán aprovecharla si se encapsulan previamente en paquetes IP. Es posible aplicar la seguridad a nivel de red de forma transparente al operador o al proveedor de servicios de Internet por lo cual es la opción que encaja de forma más adecuada con el concepto habitual de VPNs pudiendo crear lo que denominamos redes privadas virtuales seguras.

• Las VPNs a nivel de aplicación son la aproximación adoptada, por ejemplo, por:

− PEM (Privacy Enhanced Mail) o PGP (Pretty Good Privacy) en correo electrónico.

− SSH. − SNMP (Simple Network Management Protocol) versión 3. − Secure HTTP o SSL en tecnologías web.

Su ventaja es que la seguridad se puede desarrollar de forma selectiva, aplicándola únicamente en el intercambio de información confidencial o importante. El principal inconveniente es la necesidad de incorporar funcionalidades similares en cada uno de los protocolos del nivel de aplicación que deban utilizarlas, replicando así gran cantidad de tareas en diferentes partes de código. Al aplicarse los mecanismos de encriptado o validación de la información en el nivel más alto posible el nivel de seguridad

obtenido es máximo ya que se reduce el riesgo de que la información pueda ser interceptada o modificada por otros usuarios o procesos distintos del destinatario de ésta.

Ésta última es la alternativa escogida para proporcionar la encriptación de las sesiones remotas en el sistema propuesto. En resumen, se utilizarán los mecanismos existentes para implementar conexiones encriptadas a una aplicación concreta por lo que sería necesario conseguir que esta aplicación proporcione acceso al objetivo marcado, es decir, un ordenador del laboratorio.

Con las VPNs se solía decir que se había logrado “alargar” el cable de red del ordenador externo del usuario hasta la red de la empresa o institución, con este sistema propuesto, lo que se “alarga” son los cables del teclado, el ratón y el monitor, dejando la CPU (con las aplicaciones, el sistema operativo, los servidores,...) en el lugar de trabajo.

El inconveniente, probablemente más importante, sería la necesidad de disponer de un número elevado de ordenadores en el Laboratorio Ubicuo para atender las peticiones de los usuarios.

3.2.2 Virtualización

La segunda característica principal del sistema es la utilización de un software de virtualización de ordenadores donde cada máquina virtual (guest) actúa como si fuera un ordenador único sobre un mismo ordenador físico (host o anfitrión). Cada máquina virtual tiene su propio sonido, vídeo, disco duro, tarjetas de red y procesador y, además, corre su propio sistema operativo.

Los ordenadores modernos constan de múltiples niveles de hardware y software que funcionan juntos como un único sistema. Los recursos de hardware incluyen generalmente un procesador central, pantalla, almacenamiento, conexiones de red, dispositivos periféricos, etc. Los componentes del sistema operativo conocidos como controladores de dispositivo controlan recursos de hardware, traduciendo las

instrucciones del sistema operativo en un lenguaje de control de dispositivos específico. Los controladores se desarrollan con la asunción de propiedad de dispositivo exclusiva. Por ejemplo, se asume que un controlador de vídeo “posee” en exclusiva un adaptador de vídeo. Cualquier aplicación de software que llame al adaptador de vídeo debe interactuar con el hardware por medio del controlador de vídeo. Cuando las asunciones sobre la propiedad exclusiva del dispositivo se rompen, los sistemas normalmente dejan de funcionar correctamente.

El concepto de propiedad exclusiva de dispositivo generalmente descarta la posibilidad de ejecutar más de un sistema operativo al mismo tiempo en un mismo equipo. Una solución para resolver esta limitación es la tecnología de máquina virtual. La virtualización implica redireccionar interacciones con recursos de dispositivo a niveles más bajos, de tal forma que los niveles de aplicación de nivel más alto no resulten afectados.

El empleo del software de virtualización para el desarrollo de las sesiones remotas ofrece las siguientes ventajas frente a los modelos clásicos:

• Se precisan menos máquinas físicas y además su utilización de es mucho más eficiente (gestión de la capacidad de almacenamiento global, tanto por ciento del uso de la CPU, reutilización de licencias de software antiguas, clusters,...), ya que funcionan como anfitrionas de varias máquinas virtuales por cada una de ellas. Esto se traduce en una disminución significativa del coste del hardware, de su mantenimiento y del espacio requerido por el laboratorio.

• Los cambios que hagan los usuarios en las máquinas virtuales no afectan a los ordenadores anfitriones.

• Cualquier aplicación que se instale en las máquinas virtuales funcionará de la forma habitual y los dispositivos que se conecten al sistema anfitrión como impresoras, unidades de CD-ROM o DVD-ROM y demás estarán accesibles para sus máquinas virtuales.

• Si una máquina virtual provoca una excepción, ésta sólo afecta a esa máquina virtual. Ningún problema afectará a las demás máquinas virtuales o al ordenador anfitrión.

• El hecho de que todo se ejecute en un equipo físico lo convierte en una solución “plug-and-play”. Se puede automatizar la instalación o ampliación del sistema.

Los discos duros de las distintas máquinas virtuales también pueden ser virtuales, concretamente archivos en el sistema anfitrión. Si cada vez que se instala y configura correctamente un sistema se guarda una copia de seguridad, cuando se quiera recuperar una máquina que haya sufrido una desconfiguración o se quiera sustituir un sistema por otro bastará con reemplazar los ficheros que conforman el sistema a sustituir por la copia de seguridad almacenada.

Sin embargo, no todo son ventajas. También presenta algunos inconvenientes frente a los modelos clásicos:

• La utilización de software de virtualización limita la variedad de sistemas operativos que se pueden utilizar a los soportados por la herramienta.

• El empleo de herramientas de virtualización introduce ciertas peculiaridades en las máquinas virtuales que pueden delatar la utilización de este tipo de software.

• Se está trabajando en la línea de utilizar código abierto, aunque en estos momentos este tipo de herramientas están en fases de desarrollo muy tempranas.

Esta aproximación de virtualización de máquina virtual completa tiene sus orígenes en el sistema VM/370 de IBM. En principio, consideraremos tres tipos de técnicas de virtualización que permiten a una o más máquinas virtuales correr sobre una misma plataforma hardware física.

En la primera variante, como se puede observar en la Fig.2, se instala un sistema operativo en la plataforma hardware física. A continuación, se instala el programa de virtualización. Tras esta instalación se obtiene, sobre la capa de hardware física, una capa de virtualización sobre la cual se posiciona cada máquina virtual. Cada acceso a CPU, disco duro, memoria o red debe obligatoriamente pasar a través de esta capa.

La ventaja de este tipo de virtualización es que además de ésta se pueden ejecutar otras aplicaciones en el sistema operativo de la plataforma hardware física.

La desventaja de esta solución es la sobrecarga que se introduce debido a la aparición de dicha nueva capa. La plataforma hardware física necesita recursos que son únicamente necesarios para ejecutar las aplicaciones, no para las máquinas virtuales.

Fig. 2. Virtualización sobre sistema operativo estándar.

Por otro lado, se puede observar su robusta estructura y la integración e independencia con el sistema físico, la cual consta básicamente de dos bloques:

• La máquina virtual.

• La capa de virtualización.

Este tipo de virtualización funciona como cualquier aplicación corriendo sobre una plataforma hardware física. Todos los accesos al

hardware desde y/o hacia las máquinas virtuales deben pasar a través de la capa de virtualización primero y del sistema operativo instalado después para llegar y/o salir de la plataforma hardware física. Esto supondrá también la ventaja de poder registrar toda esa actividad mediante las herramientas apropiadas en el sistema operativo instalado en la plataforma hardware física. Microsoft Virtual Server 2005 y VMware GSX Server utilizan este tipo de virtualización.

Comenzando desde la parte inferior de la pila lógica, la Fig. 2 muestra lo siguiente:

• El sistema operativo anfitrión administra el sistema físico.

• La plataforma de virtualización ofrecerá un nivel de virtualización que administra máquinas virtuales, proporcionando la infraestructura de software para la emulación de hardware. Este nivel de virtualización podrá ser reubicado de manera inmediata.

• Cada máquina virtual consta de un conjunto de dispositivos virtualizados, el hardware virtual de cada máquina virtual.

• En cada máquina virtual se ejecutan un sistema operativo y las aplicaciones transparentemente, por ejemplo, a que el adaptador de red con el que interactúan a través de la plataforma de virtualización sea una emulación de software de un dispositivo Ethernet físico. Cuando un sistema operativo está funcionando en una máquina virtual, el kernel de propósito especial toma el control de la CPU y del hardware durante las operaciones de máquina virtual, creando un entorno aislado para el sistema operativo y las aplicaciones de cada máquina virtual.

Se utiliza una aplicación multiproceso que funciona como un servicio del sistema físico, con cada máquina virtual funcionando en su propio subproceso de ejecución; hay E/S en subprocesos secundarios. Se derivan dos funciones de núcleo del sistema operativo que corre en la máquina virtual: La programación de recursos de CPU y los controladores de dispositivo que proporcionan acceso a los dispositivos del sistema físico.

En el segundo tipo, ver Fig.3, no se instala un sistema operativo estándar en la plataforma hardware física sino que se instala un sistema operativo que denominaremos “auxiliar” para asegurar el acceso al hardware de la plataforma física.

Este sistema operativo auxiliar está focalizado en el proceso de virtualización. Consta de software adaptado con únicamente los módulos o servicios requeridos para éste. En consecuencia, no es posible ejecutar en paralelo otras aplicaciones además de la de virtualización. Por ejemplo, VMware ESX Server utiliza una versión de Linux especialmente adaptada como sistema operativo auxiliar.

Fig.3. Virtualización con sistema operativo auxiliar.

La ventaja de este tipo de virtualización es que no se ve limitada por la sobrecarga introducida por un sistema operativo en la plataforma hardware física y, además, el acceso al hardware desde y/o hacia las máquinas virtuales sólo debe pasar únicamente a través de la capa de virtualización para entrar y/o salir de la plataforma hardware física.

Por último, existe un tercer tipo de virtualización denominado paravirtualización que también va a permitir virtualizar y particionar de forma dinámica los recursos hardware de una máquina física, permitiendo el funcionamiento de diferentes sistemas operativos simultáneamente.

En la paravirtualización no se busca conseguir virtualizar completamente el hardware sino que se modifican los sistemas operativos que van a funcionar en las máquinas virtuales. Estos

sistemas operativos funcionarán de forma más eficiente gracias a esta adaptación la cual consistirá habitualmente en cambiar la parte del código dependiente de la máquina. Ninguna aplicación y/o librería a nivel de usuario necesitará ser modificada.

Además de exportar las instancias virtualizadas de CPU, memoria, tarjeta de red y otros dispositivos, se ofrece un interfaz de control que gestiona la compartición de estos recursos entre las distintas máquinas virtuales, denominadas dominios. El acceso al interfaz de control está restringido y sólo debe ser accesible por una máquina virtual especialmente privilegiada conocida como dominio 0. Este dominio es una parte completamente necesaria y corre la aplicación que gestiona los aspectos de la capa de control de la plataforma de virtualización. User Mode Linux y Xen utilizan este tipo de virtualización.

3.3 Arquitectura de la aplicación

La World Wide Web constituye una infraestructura electrónica de servicios relativamente uniforme que se muestra como la plataforma ideal para la realización de proyectos informáticos que incluyan entre sus objetivos la accesibilidad y la ubicuidad. Por otra parte, el sistema, además de cumplir las especificaciones docentes analizadas, debe, desde el punto de vista tecnológico, prestar su servicio sobre redes de área local, residenciales y wireless y basarse en protocolos estándar y normalizados (TCP/IP, SSL y HTTP) capaces de adaptarse a la heterogeneidad reinante. Además, la aplicación debe aislar los elementos tecnológicos lo máximo posible para permitir una mayor aceptación por los usuarios con menos formación en TIC.

Desde este punto de vista, la implementación del Laboratorio Ubicuo se ha realizado siguiendo la arquitectura cliente-servidor clásica de las aplicaciones web, distinguiéndose cuatro elementos clave: cliente, servidor Web, servidor de máquinas virtuales (MV) y sistema de información. El único de los componentes no gestionado por la infraestructura de soporte al sistema es el cliente, que se comunica

con los servidores (Web y MV) mediante el protocolo HTTP y bajo una conexión SSL para que el intercambio de datos se realice con seguridad (Fig. 4).

Los dos servidores pueden residir en el mismo equipo físico o no e, incluso, se puede disponer de uno o más servidores de MV (facilitando la escalabilidad del sistema). El intercambio de información entre los servidores de máquinas virtuales y el servidor Web se realiza mediante XML (en principio, como la infraestructura de comunicación está controlada a este nivel por la organización, no es necesario encriptar las comunicaciones).

Fig. 4. Modelo de servicios de la arquitectura del Laboratorio Ubicuo.

El sistema de información está distribuido entre los diferentes servicios proporcionados por la infraestructura de soporte a los laboratorios de la EPS más las tablas necesarias para la gestión del propio servicio de Laboratorio Ubicuo: certificados y usuarios residen en un servicio de directorio; los datos de gestión, inventario, licencias software, etc., en un gestor de base de datos MySQL, configuración de red en un servicio DHCP,… (Fig. 5).

3.4 Modelo de implementación

La implementación del Laboratorio Ubicuo se basa en dos elementos diferenciados: la lógica de gestión de la propia aplicación y el sistema de sesión remota de trabajo. El sistema de gestión representa los

mecanismos, procedimientos e interfaces que facilitan la gestión de todos los recursos del Laboratorio Ubicuo, tanto hardware como software y, cuya principal característica es que está perfectamente integrado con el sistema de gestión de laboratorios para prácticas presenciales. El sistema de virtualización de equipos de trabajo se encarga de proporcionar al usuario una sesión de trabajo en un PC virtual y remoto con las mismas condiciones que tendría el usuario en un cliente físico de un laboratorio de la Escuela Politécnica Superior.

Fig. 5. Arquitectura de desarrollo del sistema de tres niveles.

Fig. 6. Modelo con enriquecimiento en el cliente y páginas activas con ASP.

Tanto la lógica de gestión como el equipo de trabajo virtual se han desarrollado bajo tecnologías Web; en el caso del sistema de

virtualización de equipos remotos de trabajo se han empleado tecnologías de enriquecimiento en el lado del servidor y páginas Active Server Pages (ASP), mientras que para el sistema de gestión se ha utilizado la arquitectura J2SE con el modelo B2C (Fig. 6 y 7).

Fig. 7. Modelo basado en la utilización de páginas JSP y servlets.

En el lado del cliente, el único requisito que se exige al usuario es que tenga un navegador correctamente configurado para que permita la instalación del ActiveX firmado por la EPS que será el que se encargue de visualizar el escritorio remoto del sistema operativo elegido en el establecimiento de conexión.

Por otra parte, el control del flujo de la aplicación se realiza en el lado del servidor mediante tecnologías J2SE implementando la presentación de los formularios de gestión con páginas activas programadas en JSP y la funcionalidad con servlets (Fig. 7).

La funcionalidad del sistema está implementada sobre tres elementos: componente de conexión, control de las máquinas virtuales y, por último, la aplicación de gestión que hace uso de estos procesos. El diagrama de componentes de la figura 8 muestra cómo los distintos componentes se organizan según los modelos y arquitecturas analizados.

Como se observa en el diagrama de componentes (Fig. 8), existen dos módulos funcionales básicos por cada nivel identificado en la

arquitectura de servicios (Fig. 4). En el cliente, cada uno de estos módulos se encarga de proporcionar la interfaz de comunicación con el usuario para cada una de las partes lógicas componen el sistema:

Fig. 8 Diagrama de componentes.

• Para la sesión remota de trabajo se dispone de un Active X encargado de proporcionar al usuario la interacción con el escritorio de la máquina virtual remota.

• Para la gestión de la aplicación se dispone de un navegador que interpreta las páginas HTML con código javascript proporcionadas para seleccionar, conectar y finalizar las sesiones de trabajo en el equipo remoto.

• En el servidor Web se distingue el componente encargado de gestionar cuántos equipos virtuales quedan libres, de permitir o no la conexión a la máquina virtual y finalizar la sesión. Este componente se relaciona, por una parte, con el navegador del usuario para proporcionarle la interfaz que le permita indicar qué acción desea ejecutar y cuál es su resultado; con el sistema de información para obtener los datos necesarios para realizar correctamente su labor y, por último, encuesta a los servidores de máquinas virtuales para conocer el estado y disponibilidad de los equipos remotos.

Fig. 9. Diagrama de secuencia.

Por último, un servidor de máquinas virtuales que consta de un componente de virtualización que se encarga de gestionar las interacciones de los usuarios con la máquina virtual que se le ha asignado y de una página activa que permite comunicar al sistema de gestión la información necesaria sobre el estado de los equipos remotos ofertados.

Una vez identificado y autenticado un usuario por el servidor Web para el establecimiento de la sesión remota que se ejecuta en uno de los servidores de máquinas virtuales reconocidos por el sistema, se realizan los pasos que se reflejan en el diagrama de secuencia de la figura 9, donde se expone cuál es la secuencia seguida tras la identificación y autenticación de un usuario para el establecimiento de la sesión remota.

Por último, el sistema de información utilizado para la gestión del proceso de realización de prácticas reside en una base de datos

relacional (Fig. 10) y proporciona toda la información necesaria para el correcto funcionamiento y control del Laboratorio Ubicuo.

3.4.1 Componente de Conexión Web

Es el componente que nos permite interactuar con la máquina virtual en nuestro navegador web y se ejecuta físicamente en la máquina del cliente que realiza la conexión [7]. Es un control ActiveX programado con Visual Basic 6.0. Actualmente su funcionamiento es compatible con Microsoft Internet Explorer 5, Netscape Communicator 8 y versiones superiores.

La conexión se pierde de forma automática una vez se alcanza la fecha y hora máxima de conexión según se indica en los parámetros del control.

3.4.2 Procesos de control de los servidores de máquinas virtuales

Esta parte de la aplicación nos permite realizar unas determinadas funciones relacionadas con cada máquina virtual. Su ejecución se realiza en cada uno de los servidores de máquinas virtuales y ha sido programada en tecnología ASP [17]. Los parámetros también son validados con el algoritmo MD5.

Una vez llamado, este proceso devuelve un XML con el resultado.

3.4.3 Componente de Gestión

Es el componente encargado de la gestión y el control de las conexiones de usuarios a máquinas virtuales. La parte de lógica de negocio está programada con servlets, la lógica de presentación es JSP, HTML, CSS y javascript y, en cuanto a la lógica de datos, se emplea una base de datos MySQL.

3.5 Base de datos

La base de datos debe proporcionar información de dos tipos: configuración y registro. La información de configuración le indica al

resto de módulos del sistema los datos necesarios para su correcto funcionamiento indicándole cómo se tiene que comportar y de qué recursos disponen. La información de registro se utiliza para almacenar la actividad que ocurre en el laboratorio.

El esquema relacional de la figura 10, muestra las entidades y las relaciones entre éstas del sistema de información del Laboratorio Ubicuo.

Fig. 10. Modelo Entidad – Relación.

4 Conclusiones

Con la tecnología de sesiones remotas se pueden ejecutar y ofrecer de forma segura a través de Internet, al mismo tiempo, múltiples entornos operativos a usuarios que utilizan una misma plataforma cliente y, además, todos ellos sobre un mismo servidor físico (o varios). Cada máquina virtual tendría su propio sistema operativo y puede ejecutar aplicaciones de manera independiente. La plataforma

de virtualización ofrece una capa entre, por un lado, el hardware físico de computación, almacenamiento y comunicaciones y, por otro lado, el software que se ejecuta.

La tecnología de máquina virtual puede reducir el coste de la tecnología de la información mediante el aumento de la eficiencia, flexibilidad y capacidad de respuesta. Cada una de ellas actúa en un entorno separado, lo que reduce riesgos y permite volver a los estados iniciales de las diferentes configuraciones de sistemas operativos ofrecidas o comparar fácilmente versiones de aplicaciones diseñadas para diferentes sistemas operativos, por nombrar sólo dos de sus posibles aplicaciones.

En este capítulo se resumen las tecnologías utilizadas para el sistema de sesiones remotas virtuales de la Escuela Politécnica Superior de la Universidad de Alicante y las alternativas tecnológicas existentes y se proporcionan ejemplos de escenarios de uso.

Resulta de enorme interés destacar que el sistema presentado en este capítulo está siendo integrado con el sistema ya existente de gestión de laboratorios de la Escuela Politécnica Superior de la Universidad de Alicante, también presentado en JDARE’05, aprovechando las sinergias existentes y realizando las adaptaciones necesarias para que el usuario del sistema de sesiones remotas disponga de un entorno que se asemeje en todo lo posible a su trabajo en el laboratorio de ordenadores presencial.

Esto es debido a que la EPS de la UA tiene la responsabilidad de la gestión de los laboratorios de prácticas docentes de las titulaciones asignadas a este Centro. Entre estas titulaciones se encuentran disciplinas tan dispares como la Ingeniería Informática, la Arquitectura, la Ingeniería Técnica de Obras Públicas y la Ingeniería Técnica de Telecomunicaciones, en su especialidad de Sonido e Imagen. En un entorno tan heterogéneo, establecer una estrategia de gestión válida para todos los actores implicados no es fácil y ha requerido un minucioso análisis y una propuesta clara y consensuada de las políticas de gestión y utilización de sus recursos.

En [18] se hizo una descripción en detalle del modelo de gestión desarrollado por la EPS que, además de establecer un marco de convivencia entre las diferentes titulaciones, asignaturas, departamentos, alumnos y profesores de la EPS, proporciona herramientas de apoyo a la docencia práctica y establece los mecanismos necesarios para garantizar un mínimo de seguridad.

Por último, se está trabajando en la virtualización de todo el proceso de docencia práctica. El trabajo que se ha presentado en este capítulo proporciona un laboratorio de prácticas libre enfocado a la realización de prácticas por parte del alumno al margen de la docencia autorizada por un profesor. En la actualidad, el servicio técnico de la EPS ha avanzado en el desarrollo del Laboratorio Ubicuo, con el que se pretende virtualizar todo el proceso docente práctico, desde la entrada al laboratorio, la tutorización de las prácticas con la interacción entre profesores y alumnos y, por último, la salida del laboratorio.

5 Agradecimientos

Alberto Seva Follana, técnico del departamento de Física, Ingeniería de Sistemas y Teoría de la Señal de la Universidad de Alicante. Los autores desean agradecer su entusiasmo y perseverancia en las fases preliminares a la concepción del proyecto.

Especialmente los autores desean agradecer su apoyo al Grupo M, el grupo de redes perteneciente a la unidad singular de investigación Informática Industrial y Redes de Computadores del departamento de Tecnología Informática y Computación de la Universidad de Alicante.

6 Referencias

1. Manuel Area Moreira, "¿Qué aporta Internet al cambio pedagógico en la Educación Superior". R. Pérez (Coord): Redes multimedia y diseños virtuales. Actas del III Congreso Internacional de Comunicación,

Tecnología y Educación. Universidad de Oviedo, septiembre 2000, pp. 128-135.

2. Manuel Area Moreira, "Nuevas tecnologías, educación a distancia y la mercantilización de la formación" Revista Iberoamericana de Educación. ISSN: 1681-5653.

3. F. Llorens, C. Sánchez y otros, “Especial universidades: Las universidades españolas incrementan sus recursos TIC”. Socinfo. Sociedad de la Información. Administraciones Públicasn [revista]. Núm. 15 http://www.socinfo.info/contenidos/pdf15/p38-52universidades.pdf [Fecha de consulta: 01/05/05].

4. “Informe Asignaturas de Libre Elección mediante Teleformación curso 2003/2004”, Gabinete de Tele-Educación de la Universidad Politécnica de Madrid. http://www.gate.upm.es/evaluacion/documentos/informesevaluacion/Informe0304.pdf. [Fecha de consulta: 01/04/05].

5. A. Beth Campbell y R. P. Pargas, “Laptops in the Classroom”. Technical Symposium on Computer Science Education. Proceedings of the 34th SIGCSE technical symposium on Computer science education Reno, Nevada, USA

6. Gregory B. Newby, "Student Laptop Ownership Requirement and Centralization of Information Technology Services at a Large Public University." Annals of Cases on Information Technology v5: 206-217. Hershey, Pennsylvania: Idea Group Publishing.

7. Mª Carmen Capote Morales, Alicia Verónica García Espósito, "Un estudio sobre las TICs y el alumnado universitario" ComByte 2004: Un nuevo sujeto para la sociedad de la información. Univesridad de Las Palmas de Gran Canaria. Abril, 2004.

8. J. M. Duart, F. Lupiáñez, “E-strategias en la introducción y uso de las TIC en la universidad”. Las TIC en la universidad: estrategia y transformación institucional [monográfico en línea]. Revista de Universidad y Sociedad del Conocimiento (RUSC). Vol. 2, núm. 1. Universitat Oberta de Catalunya (UOC). ISSN 1698-580X. http://www.uoc.edu/rusc/dt/esp/duart0405.pdf. [Fecha de consulta: 01/05/05].

9. A. Albaladejo, J.A. Gil, “Infraestructuras para el desarrollo e implantación de aplicaciones de red escalables”. Desarrollo de grandes aplicaciones

distribuidas sobre Internet. JDARE'04, Alicante. pp. 1-30. Mayo 2004. ISBN: 84-7908-815-X.

10. A. Albaladejo, J.A. Gil, J.J. Zubizarreta, “Diseño de Sistemas de Información. Un caso práctico”. Desarrollo de grandes aplicaciones distribuidas sobre Internet. JDARE'04, Alicante. pp. 49-68. Mayo 2004. ISBN: 84-7908-815-X.

11. F. A. Candelas, J. Sánchez "Recursos didácticos basados en Internet para el apoyo a la enseñanza de materias en el área de Ingeniería de Sistemas y Automática." Revista Iberoamericana de Automática e Informática Industrial. Vol. 2 Núm. 2: pp. 93-101. Abril 2005. ISSN: 1697-7912.

12. Engineering Department, University of Cambridge. http://www-h.eng.cam.ac.uk/help/pnt/mindterm/. [Fecha de consulta: 01/03/05].

13. Harvard - MIT Data Center. http://www.hmdc.harvard.edu. [Fecha de consulta: 01/03/05].

14. MindTerm. http://www.appgate.com/mindterm. [Fecha de consulta: 01/03/05].

15. Laboratorios del Departamento de Ingeniería de Sistemas Telemáticos. Universidad Politécnica de Madrid http://www.lab.dit.upm.es. [Fecha de consulta: 01/03/05].

16. 16. Microsoft Virtual Labs. http://microsoft.demoservers.com/technet/. [Fecha de consulta: 01/03/05].

17. Microsoft Developer Network (MSDN). http://msdn.microsoft.com . [Fecha de consulta: 01/05/05].

18. Gil, J.A., “Modelo de gestión y seguridad en aulas informáticas”. II Jornadas sobre desarrollo de grandes aplicaciones de gestión de red. Departamento de Tecnología Informática y Computación. Universidad de Alicante. http://orion.dtic.ua.es/jdare05/. [Fecha de consulta: 01/05/05].