GAP: Una Herramienta para Solucionar el Problema de la Visualización de Contenidos Web en Dispositivos Pocket PC

GAP: Una Herramienta para Solucionar el Problema de la Visualización de Contenidos Web en Dispositivos Pocket PC. J. Carlos Olivares R., J. Gabriel González S., Azucena Montes R.,Víctor J. Sosa S. e I Rafael Ponce M. Centro Nacional de Investigación y Desarrollo Tecnológico (cenidet) {jcolivares04c, gabriel, amr, vjsosa, rafaxzero04c}@cenidet.edu.mx

Abstract Esta herramienta trata de llenar el “hueco” presente en la visualización de sitios Web en dispositivos móviles PDA, caso concreto Pocket PC. Para garantizar que los usuarios puedan visualizar correctamente los recursos de Web, se necesitan dos cosas: un mecanismo que controle desconexiones y permita visualizar contenido Web sin importar el estado de conexión del dispositivo (acaparamiento), y un mecanismo que adapte el contenido de la Web a las características propias del dispositivo móvil específico (transcodificación). GAP es una herramienta que integra estos dos mecanismos y permite mejorar la experiencia de navegación de los usuarios en la Web Móvil. Palabras clave: Pocket PC, Visualización de Contenidos Web, Acaparamiento, Transcodificación.

1. Introducción Los dispositivos móviles están más cerca de lo que parecen estar, de acuerdo con [1]: “Para el año 2009, más de la mitad de los microprocesadores fabricados en el mundo estarán destinados a dispositivos móviles. El software que hará realmente útiles a los dispositivos móviles todavía no es desarrollado.” Estas estadísticas reflejan que el uso de dispositivos móviles va en creciente aumento debido principalmente a su diminuto tamaño y a que su poder de procesamiento y versatilidad van creciendo día con día. El problema de la visualización de recursos de Web en dispositivos móviles, radica en el hecho de que la gran mayoría de los sitios Web en Internet no han sido diseñados para esta clase de dispositivos. Los cuales cuentan con recursos de cómputo limitado (pantallas pequeñas, poca memoria, velocidades bajas de procesamiento, etc.) si se comparan con un equipo de cómputo tradicional. Por otra parte, la Web y el protocolo que lo gestiona: HTTP, son orientados a conexión (se basan en TCP) lo cual da como resultado de que si el usuario

por algún motivo se desconecta de la red, la transacción falle. En este caso, no se podría visualizar los recursos de la Web en el cliente móvil. Las desconexiones son frecuentes en esta clase de dispositivos, debido en gran medida a una de sus principales ventajas: la movilidad. En este trabajo se describe un sistema cuyo trabajo está en progreso y que se enfoca a atacar el problema de la visualización de recursos de Web en dispositivos móviles. La característica principal de este trabajo, radica en que gran parte del sistema se ejecuta en esta clase de dispositivos, en comparación a la gran mayoría de las soluciones existentes que se ejecutan en plataformas de cómputo tradicional.

2. Alternativas de solución Para solucionar este problema se han propuesto varias alternativas: diseñar nuevos protocolos, modificar protocolos o implementar servicios intermediarios que resuelvan el problema.

2.1 Nuevos protocolos En este esquema se puede citar al protocolo WAP y al lenguaje de marcado WML, los cuales funcionan de manera análoga a HTTP-HTML en la Web tradicional. El problema radica en que WAP sólo trabaja con equipos móviles y traería consigo la misma fragmentación de la Web que se vive actualmente (páginas especiales para toda clase de dispositivos). Además, WAP se diseñó originalmente para dispositivos con capacidades de cómputo limitada (pantallas monocromáticas, bajo ancho de banda, etc.) lo que para en estos momentos se está solucionando día con día por medio de conexiones de banda ancha inalámbrica (WCDMA, UTMS, 802.11g, WiMax, etc.) y equipos cada vez más potentes. La mejor solución sería crear un nuevo protocolo. El problema es que éste debe de ser totalmente compatible con los existente por que sino, dejaría

inservible miles de recursos ya existentes (se deberían de modificar tanto clientes como servidores Web).

2.2 Modificación de protocolos Dentro de esta alternativa se tiene el caso de un nuevo esquema de petición de los recursos Web. Este nuevo esquema recibe el nombre de Push, mientras que el esquema tradicional recibe el nombre de Pull[2]. El esquema Pull recibe el nombre de ‘sobre demanda’. Bajo este esquema, es el cliente (usuario) que de manera explícita visualiza un recurso. En nuestro caso, si un usuario quiere ver la página del cenidet, tiene que escribir en su navegador la URL: http://www.cenidet.edu.mx/. El esquema Push también recibe el nombre de ‘subscripción-notificación’. En este esquema, el usuario se subscribe a un servicio y cada vez que haya ocurrido algún evento de interés para el usuario se le envía una notificación alertándolo sobre el evento. Generalmente estos dos esquemas no viven de manera aislada. Esquemas híbridos (Pull&Push) se han aplicado en diversos servicios existentes, tal es el caso de la recepción de mensajes SMS/MMS, en donde el envío de mensajes es Pull y la recepción es Push, ya que se le notifica a los usuarios de la existencia de nuevos mensajes. Otro servicio que ha tenido gran éxito y que ha hecho famoso a dispositivos como los Blackberry es el Push-mail[3]. Bajo el esquema tradicional del correo electrónico, un usuario para consultar su correo debe de estar conectado todo el tiempo para recibir correo. Esto con lleva a grandes gastos si la conexión a la red se factura por tiempo. Con este nuevo esquema, el usuario no está conectado al servidor de correo. Cuando se recibe un nuevo correo en el servidor, éste notifica al cliente de la existencia del nuevo correo y lo envía al cliente móvil. Para este tipo de esquemas, se han propuesto protocolos como HTTPU (HTTP over UDP) o HTTPMU (HTTP over Multicast UDP) que básicamente funciona similar al HTTP pero utilizando datagramas, los cuales no están orientados a conexión. Con esto se logra una mejor calidad de servicio en la Web móvil[4].

2.3 Servicios intermediarios Esta es la solución más extendida para solucionar el problema de la visualización de recursos Web y muchos otros problemas que presenta la Web, tal es el caso de los muros de fuego que solucionan alguno de los problemas de seguridad de la Web como el control

de acceso o los proxys caché, que tratan de reducir la latencia de acceso a la información. El esquema de intermediarios es ampliamente usado por que no necesita modificar ni los clientes ni los servidores; de hecho, los procesos cliente y servidor no notan la existencia de dichos servicios intermediarios. Estos servicios se encargan del trabajo pesado y son transparentes hacia los usuarios. La herramienta que se describe en este artículo, funciona bajo el esquema de servicios intermediarios.

3. Propuesta de solución El proceso de acaparamiento soluciona el problema de la visualización de recursos Web sin importar el estado de la conexión del dispositivo móvil. Para ello, se hace necesario que el usuario tenga almacenados de manera local en su dispositivo los recursos que usará. Como se puede observar, la cantidad de recursos a ocupar puede ser inmensa, mientras que la capacidad de almacenamiento de los dispositivos es limitada. Para dar solución a este nuevo problema, es necesario tener una manera efectiva de conocer los recursos que un usuario podría utilizar. Con el acaparamiento se logra reducir esto, ya que a través de algoritmos de reglas de asociación aplicados sobre bitácoras Web, determina el conjunto óptimo de recursos que deberán replicarse a los clientes móviles[5]. Para solucionar el problema de la adaptación de los recursos Web a las capacidades de despliegue de los dispositivos móviles, se necesita de la transcodificación (transformación) de los recursos, destilando y procesando todas aquellas características que no estén disponibles en el dispositivo. El mecanismo utilizado de transcodificación utiliza un transformador de HTML a un subconjunto de HTML utilizando XML. El sistema se basa en una arquitectura clienteservidor con una capa intermedia tanto del lado servidor como del lado cliente, tal y como se muestra en la Figura 1. El sistema en general ha sido denominado GASWT (Gestor de Acaparamiento de Sitios Web Transcodificados). Al intermediario en el lado cliente se denomina GAP (Gestor de Acaparamiento para Pocket PC), mientras que en el lado servidor se denomina GAT (Gestor de Acaparamiento y Transcodificación). El GAT se compone a su vez del MA (Mecanismo Acaparador) y del MT (Mecanismo Transformador). La comunicación entre los procesos se realiza a través de un esquema de petición-respuesta en HTTP. Tanto el MA como el MT son tomados de otros proyectos que en conjunto con éste, forman parte del

proyecto Moviware[6], cuya función principal es brindar una serie de servicios a clientes móviles propensos a desconexiones frecuentes. Dispositivo móvil Pocket PC

MA

Navegador Petición - Respuesta HTTP

Squid

Web

Petición - Respuesta HTTP

GAP

Petición - Respuesta HTTP

MT Petición - Respuesta HTTP Si el recurso no está en la caché

GAT

Figura 1. Arquitectura general propuesta.

El funcionamiento general del sistema es el siguiente. El usuario introduce una URL desde su navegador (que previamente ha sido configurado para redireccionar su salida hacia el GAP). El GAP recibe la petición y determina si se encuentra en la caché local del dispositivo, si la encuentra, envía el recurso acaparado al navegador. Cuando el recurso no se encuentra acaparado, se valida que exista conexión y se trata de obtener el recurso en línea. Si por alguna razón el recurso no se puede mostrar, (ya sea que no exista o se hay detectado un error en la conexión) se notifica al usuario enviando un mensaje de error. Por otra parte, si el recurso Web no se encuentra acaparado y no existe un patrón del sitio en el dispositivo local, el MA envía los recursos Web si es que existe el patrón para dicho sitio. Si existe el patrón pero no se tienen los recursos acaparados en el MA, éste los obtiene pidiéndolos al MT y luego los comprime en formato .zip para optimizar el proceso. Una vez que el MA ha enviado el sitio Web acaparado, el dispositivo móvil debe descomprimir el sitio Web y actualizar su lista de patrones. Este proceso ocurre de manera transparente sin que el usuario lo perciba. El MT se encarga de recolectar los documentos y en caso de ser recursos HTML, los transforma si es que los parámetros de configuración así lo indican. La transcodificación se realiza en línea, por lo que el proceso se ve ralentizado si el documento es demasiado grande. Las acciones que el usuario puede realizar sobre el sistema consisten en visualizar sitios Web en línea, visualizar sitios Web en desconexión, Visualizar mensajes de error, visualización del estado de las peticiones y por último, configurar el sistema.

El GAP está conformado básicamente de tres módulos principales y varios secundarios. Los módulos principales son: Observador, Gestor de Acaparamiento Local (GAL) y Gestor de Desconexión Local (GDL). El Observador se encarga de procesar cada petición y devolver el resultado al navegador. El GAL se encarga de la manipulación y control de la caché en el dispositivo. Es el usuario quien decide que recursos se desean acaparar, así como limitar el espacio de almacenamiento. El GDL se encarga de determinar el estado de la conexión. Para éste último punto, se ha utilizado el control de las desconexiones sondeando la red durante tres segundos. En base a Observaciones de la calidad de los resultados, se fijó un umbral de 30% de conexiones aceptadas para determinar si el cliente se encuentra conectado (si se supera o iguala el umbral) o en modo desconexión (si se encuentra por debajo del umbral)[7]. Para la implementación de esta herramienta, se está utilizando la plataforma .NET Compact Framework 1.0 con lenguaje C#, por ser por mucho la mejor opción para programar en esta plataforma[8]. Las modificaciones del MA y del MT se están realizando en Java por que es lenguaje en el cual están hechos estos módulos.

4. Resultados La herramienta descrita en el presente documento se ha probado en diversos equipos como Pocket PC 2000 (Compaq ipaq h3630), Pocket PC 2002 (HP Jornada 5500), Pocket PC 2003 (HP rx3115), emuladores de Windows CE, PC convencionales (Compaq Presario Pentium 4 1.4 Ghz 512Mb de RAM). El primer escenario de prueba consistió en acceder a los recursos Web en modo conexión. Obteniendo resultados satisfactorios (ver Figura 2). En el escenario de prueba número 2, el GAP se ejecutó sin estar conectado a la red. Adicionalmente se contaba con un patrón de un sitio Web (http://www.cenidet.edu.mx/) y recursos acaparados. En este caso se utilizaron imágenes no existentes en el sitio original, por lo que se pudo comprobar que los recursos acaparados se muestran correctamente (Figura 3). El escenario de prueba número 3 (ver Figura 4), demuestra que es posible transcodificar los recursos en el dispositivo así como de mostrarlos de manera local si se encuentran acaparados como en el caso anterior. También es posible ejecutar el GAP en otras plataformas como Smartphones (SmartGAP) y PC tradicionales (WinGAP). Cabe hacer mención que

tanto GAP, WinGAP y SmartGAP son el mismo programa pero con nombre distinto, para diferenciar la plataforma en la cual se ejecutan.

2.

3. 4.

5.

Reducción de latencia en el acceso a la información, si es que el recurso se encuentra acaparado localmente. Ahorro de energía por el hecho de trabajar en modo desconexión Ahorro de dinero si es que el usuario decide no conectarse a una red que cobra el servicio por el tiempo de acceso. Facilidad de administración de sitios Web al no disponer de diferentes versiones para cada dispositivo.

Figura 2. Visualización de recursos Web en modo conexión.

Figura 4. Visualización de sitios Web en modo conexión, con recursos acaparados y transcodificados.

6. Referencias Figura 3. Visualización de sitios Web en modo desconexión con recursos Web acaparados y sin transcodificación.

5 Conclusiones Con la presente herramienta se está demostrando que es posible ejecutar servicios complejos en dispositivos Pocket PC, tal es el caso de un servicio intermediario que permite visualizar recursos de Web cuando exista o no conexión. Hasta el momento se han podido comprobar de manera aislada la mayoría de las funciones del sistema (falta los métodos de descompresión del sitio Acaparado), ya simplemente solo haría falta la integración de componentes y las pruebas respectivas al sistema en su totalidad. Los beneficios que se esperan obtener al concluir este trabajo de investigación son los siguientes: 1. Visualización de sitios Web sin importar si los dispositivos están conectados o no.

[1] Revista SG, http://www.softwareguru.com.mx [consultado marzo de 2006] [2] Purushottam Kuikarni, et al., “Handling Client Mobility and Intermittent Connectivity in Mobile Web Accesses”, Department of Computer Science, University of Massachussets. [3] Blackberry’s push technology, http://www.blackberry.com/products/software/integrations/p ush_email.shtml [consultado marzo de 2006] [4] UPnP Forum, http://www.upnp.org/, [consultado marzo de 2006] [5] David Valenzuela, “Mecanismos para predicción de acaparamiento de datos en sistemas clientes/servidor móviles”, tesis de maestría, cenidet, agosto de 2002. [6] Gabriel González. “Plataforma middleware reflexiva para aplicaciones de cómputo móvil en Internet (Movirware)”, cenidet. [7] J. Carlos Olivares, et al, “Control de desconexiones en la visualización de páginas Web en dispositivos móviles Windows CE”, XVI CIECE’06 a 5, 6 y 7 de abril de 2006 en Cd. Obregón, Sonora, México. [8] Gabriel González, Azucena Montes, J. Carlos Olivares, “Comparativa y evaluación de las herramientas de programación para desarrollar aplicaciones en plataforma Pocket PC”. 6to. CICC’05, Colima, Colima, México, septiembre de 2005.