Artículo en Español de la Revista IEEE Looking Forward

1. 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
17

2. 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 cliente-
servidor 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.
18

3. 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.
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).
GAP
MA
MT
Navegador
Squid Web
GAT
Dispositivo móvil
Pocket PC
Petición - Respuesta
HTTP
Si el recurso no
está en la caché
Petición - Respuesta
HTTP
Petición - Respuesta
HTTP
Petición - Respuesta
HTTP
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.
19

4. 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.
Figura 2. Visualización de recursos Web en modo
conexión.
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.
2. Reducción de latencia en el acceso a la
información, si es que el recurso se encuentra
acaparado localmente.
3. Ahorro de energía por el hecho de trabajar en
modo desconexión
4. Ahorro de dinero si es que el usuario decide no
conectarse a una red que cobra el servicio por
el tiempo de acceso.
5. Facilidad de administración de sitios Web al no
disponer de diferentes versiones para cada
dispositivo.
Figura 4. Visualización de sitios Web en modo
conexión, con recursos acaparados y
transcodificados.
6. Referencias
[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
20

5. Pocket PC”. 6to. CICC’05, Colima, Colima, México,
septiembre de 2005.
21