A N Lisis D E Tecn Olog As Sw P Ara Lab Oratorios Rem Otos

Análisis de tecnologías sw para laboratorios remotosJavier García Zubía *, Pablo Orduña *, José María Sáenz Ruiz de Velasco **, InésJacob Taquet **, Jesús Luis Díaz Labrador ** y Javier Oliver Bernal *** Dpto. de Arquitectura de Computadores, Automática y Electrónica y Telecomunicaciones** Dpto. Ingeniería del softwareUniversidad de DeustoAvda. Universidades 24, 48007, Bilbao, Españazubia@eside.deusto.esResumenLos Laboratorios Remotos o WebLab son ya unrecurso didáctico de primer orden en lasfacultades de ingeniería, sin embargo en muchoscasos adolecen de un pobre diseño sw, tanto en elcliente como en el servidor, lo que degrada sucalidad y su utilidad académica. El presentetrabajo analiza y selecciona las mejorestecnologías para implementar el cliente y elservidor de un WebLab.1. IntroducciónActualmente los WebLabs han demostradosobradamente su utilidad académica no tanto parasustituir a los laboratrios presenciales, como paracomplementarlos y potenciarlos. En una primeraetapa, los WebLabs estaban organizados ypromovidos por un laboratorio o departamento,pero su éxito ha conllevado que deba ser la propiauniversidad la encargada de ofrecer este servicio.Este cambio supone un reconocimiento para losWebLabs, pero también nuevos requisitos(seguridad, accesibilidad, universalidad, etc.) quegeneralmente no son tomados como esenciales alinicio del diseño, pero que son los que conformanun servicio profesional. Un planteamientoincorrecto es diseñar primero un prototipo quefuncione –it runs- y luego añadirle ento no es válido y muchas veces acabaen que hay que rehacer la totalidad de laaplicación. Esto es fácilmente asumible por unprofesional de la informática, pero no es tanevidente en otros casos.Por ejemplo, en el mes de noviembre del 2006la Universidad de Deusto organizó un workshopinvitando a una decena de investigadores en elárea de los laboratorios remotos [1]. Buena partede las dicusiones se centraron en los aspectos hwy académicos, pero sin embargo quedó patenteque no era lo mismo desarrollar en Java, que enAdobe o en AJAX, y que una mala eleccióninicial de la tecnología lastraba la calidad dellaboratorio remoto, sobre todo en aspectosesenciales como la universalidad, la seguridad y laaccesibilidad.Lasrazonessonquemayoritariamente los investigadores tienen unperfil electrónico o de regulación y que lastecnologías web 2.0 son de reciente aparición.Otro ejemplo clarificador se obtiene al leer elimponente trabajo [2]. En él se analizan más de uncentenar de artículos centrados en laboratorios,pues bien, solo uno de ellos [3] relaciona sw ylaboratorios remotos, centrándose el resto en elhw y en los aspectos académicos.Figura 1. Evolución tecnológica del WebLabDeusto.

146Robótica e informática industrial /Arquitectura de ordenadoresEl presente trabajo aprovecha la experiencia delequipo investigador desde el 2001 en el desarrollode WebLabs (ver Fig. 1 y [4][5][6]) para analizary seleccionar entre las tecnologías propias delcliente y del servidor la más adecuada paradiseñar un laboratorio remoto. El trabajo describelas necesidades de un WebLab, las posibilidadesde las diferentes tecnologías para el cliente –aplicaciones de escritorio, ActiveX, Java, AdobeFlash, AJAX y HTML– y las correspondientes alservidor –Python, .NET y Java.Los apartados 2 y 3 describen y analizan lasdistintas tecnologías para implementar el cliente yel servidor de un WebLab, seleccionandojustificadamente una para cada entorno, AJAX yPython, respectivamente. El apartado 4 refleja lasconclusiones del trabajo.2. Aplicación del clienteEl cliente en un laboratorio remoto es el sw que elusuario va a utilizar para acceder al servicio.Dependiendo del experimento, el cliente puedenecesitar enviar un fichero, o recibirlo; puedenecesitar ver por WebCam qué está pasando en ellaboratorio; puede necesitar interactuar con elexperimento; o puede necesitar otros servicios.La parte cliente debería evitar cualquierrestricción innecesaria en el usuario más allá delas funcionalidades, es decir, cualquier alumnocon cualquier PC, SO y navegador debe poderacceder al WebLab, ya que lo contrario esdifícilmente asumible por la universidad (aunquesí podría serlo por el laboratorio). Así pues, uncliente es mejor cuanto más “fino” es, cuanto másSO soporta, cuanto más accesible es, cuantomenos dependiente es de plug-in, etc. LosWebLabs deben ser herramientas didácticasuniversales.2.1. Tecnologías del clienteActualmente existe un abanico muy amplio detecnologías que pueden ser utilizadas paraimplementar el cliente de un laboratorio remoto,desde la más ligera aplicación web hasta la máspesada aplicación de escritorio. Todas ellaspueden ser clasificadas en dos grupos:x Aplicaciones de escritorio. Aquellas que seejecutan en el escritorio del ordenador delusuario.x Aplicaciones web. Aquellas que sonejecutadas en el navegador del escritorio delusuario.Una aplicación de escritorio puede serdesarrollada en muchas plataformas (C, C ,Delhi, Java, .NET, Python, etc) y tener muy pocasrestricciones, pero es poco portable, más intrusivaque las aplicaciones web, ya que usualmentetienen acceso a todo el sistema del usuario, ynecesita de un proceso de instalación. Estasdesventajas se compensan con una mayor potenciay complejidad, ya que al no tener las restriccionespropias de un navegador y de los estándaresasociados a él, estas aplicaciones pueden explotarpor cuenta propia recursos como 3D, protocolosbinarios específicos para la aplicación, etc. Encualquier caso la calidad y seguridad de unaaplicación de escritorio recae totalmente en sudiseñador y programador, y esto desde el punto devista del administrador de sistemas de launiversidad suele ser totalmente inaceptable a noser que ellos hayan sido los desarrolladores; no sedebe olvidar que este departamento es elencargado de asegurar y ser responsable de laintegridad del servicio informático de launiversidad, y que un mal diseño puedecomprometerla.Atendiendo a las razones anteriores, el trabajose va a centrar principalmente en las aplicacionesweb, que junto a las aplicaciones de escritorio,pueden reclasificarse en:x Aplicaciones intrusivas. Estas aplicacionestienen los mismos privilegios que lasaplicaciones del usuario, por ejemplo puedenacceder al disco duro, pueden leer y escribirficheros, pueden ejecutar programas, puedenabrir y cerrar conexiones, etc.x Aplicaciones no intrusivas. Estas aplicacionesgarantizan al usuario que pueden ejecutadassin poner en riesgo su seguridad, ya que nopueden hacer nada que no pueda hacer elnavegador en el que están siendo ejecutadas.Figura 2. Clasificación de las tecnologías delcliente

XIII Jornadas de Enseñanza Universitaria de la InformáticaViendo la Fig. 2 se puede decir que cuanto máspotente es una tecnología, menos universal y másintrusiva es. Conceptualmente, la mejor tecnologíaes aquella que cubriendo todos los requisitos delsistema, más universal sea. El resto del trabajo vaa analizar las diferentes estrategias para acabarseleccionando AJAX, ya que aunque no es la máspotente sí es la más universal, y en el caso de unservicio académico su “universalidad” es unrequisito irrenunciable.Aplicaciones de escritorioSon las más intrusivas y las que máscomprometen la seguridad del usuario.Específicamente las tecnologías Java y .NETpueden ser no intrusivas bajo control del usuario[7] [8]. En cualquier caso su calidad dependeclaramente del equipo de desarrollo, y por tantono serán tenidas en cuenta en el análisis final.ActiveXJava y ActiveX son probablemente, entre lastecnologías de aplicaciones web, los sistemas máspotentes en términos de flexibilidad, pero ActiveXsolo está disponible bajo Internet Explorer y susaplicaciones son por defecto intrusivas, aunque elcliente debe aceptar la ejecución de sw intrusivo.Estas características hacen que las aplicaciones enActiveX estén más cerca de las aplicaciones deescritorio que de las aplicaciones web.Java appletsJava es una plataforma potente para desarrollarRich Internet Applications, RIA. Para poder usarJava, el cliente debe tener instalada la máquinavirtual de Java, JRE [9] [10].Una buena característica de Java es que puedeser instalada en diferentes sistemas operativos, ypuede ser embebida en muchos navegadores. Ladesventaja de JRE es su disponibilidad, que sibien era mucha hace tres o cuatro años, ahora estáempezando a decrecer, y no todos los ordenadoresla tienen instalada. Otra desventaja es que si elWebLab ha sido desarrollado para JRE 1.5, nofuncionará para JRE 1.4, y el usuario tendrá queactualizar la máquina virtual, pero además, y aunsiendo extraño, una aplicación hecha bajo JRE 1.3puede no funcionar bajo JRE 1.5, todo esto exigeal usuario tener disponibles varias máquinasvirtuales y saber bajo cuál debe ejecutar cadaaplicación, y/o exige a los desarrolladores tenerdiferentes versiones de un mismo WebLab para147las diferentes JRE, con el problema demantenimiento que esto supone.Es interesante volver sobre la disponibilidadde la JRE, ya que si no está instalada y el usuarioestá en un cibercafé o en un ordenadoruniversitario sin privilegios de administrador, nopodrá instalar la máquina virtual y por tanto nopodrá acceder al laboratorio remoto, quedandodegradada su universalidad.Por último cabe destacar que una aplicaciónJava no es inicialmente intrusiva ya que se ejecutaen la sand box, pero si el cliente debe acceder aalgún fichero, entonces la aplicación deberá“abandonar” la sand box, convirtiéndose en unaaplicación intrusiva, perdiendo una de susprincipales ventajas. La solución a este problemapodría implementarse en HTML o JavaScriptdentro de la aplicación Java, pero esto complicaríainnecesariamente el desarrollo y mantenimientodel sistema.Adobe FlashAdobe Flash [11] es actualmente la tecnologíalíder en RIA. El usuario de una aplicación AdobeFlash debe tener instalado el Adobe Flash Player,el cual interpretará los ficheros en formato swf.Una vez instalado el Adobe Flash Player, lasaplicaciones desarrolladas serán no intrusivas,multiplataformas y muy potentes: vídeo, vídeo entiempo real, sonido, acceso no intrusivo aficheros, uso de ActionScript, acceso a serviciosweb, etc. La combinación del potencial de AdobeFlash en servicios web y en animación hacen deesta tecnología una de las más adecuadas paraimplementar laboratorios remotos.El uso de Adobe Flash está muy extendido yestá disponible en Windows, Linux y Mac OS[12]. En cualquier caso esta disponibilidad esrelativa ya que todavía no está disponible para 64bits, lo que es una clara desventaja. Además, laversión 7 es la única disponible para Linux hastamediados de enero de 2007, mientras que paraWindows ya está desarrollada la versión 9 [13].Otro problema importante es que solo tiene ungran distribuidor, Adobe, y es por tanto un swpropietario. Por ejemplo, en diciembre de 2006fue descubierto un error de seguridad en AdobeReader que comprometía gravemente a Windows[14], de tal forma que si el site tenía disponible unpdf, la sesión del cliente podía ser robada. Estomismo podría pasar con el Adobe Flash Player y