Este documento presenta una propuesta para resolver el problema de las frecuentes desconexiones en clientes móviles como las Pocket PC al visualizar páginas web. Propone utilizar una técnica llamada acaparamiento que replica y procesa contenido web localmente para permitir el acceso offline, así como la transcodificación del contenido para adaptarlo a las limitaciones de pantalla de los dispositivos móviles. Explica conceptos como acaparamiento, transcodificación y características de las Pocket PC.

1. Gestor de Acaparamiento de Sitios Web
Transcodificados para Plataforma Pocket PC
Juan Carlos Olivares R. 1
, J. Gabriel González Serna1, 2
, Azucena Montes Rendón1
1
Centro Nacional de Investigación y Desarrollo Tecnológico
Cuernavaca, Morelos, 62490 México
1, 2
Centro de Investigación en Computación (CIC-IPN)
México, D.F.
Resumen: Dado el gran auge que ha tenido los
dispositivos móviles, en este artículo se presenta
una propuesta de solución para el problema de
las frecuentes desconexiones en clientes móviles
del tipo Pocket PC, en lo referente a la
visualización de páginas Web. También se
muestra el estado de arte y marco teórico de esta
tecnología.
Abstract: This paper shows a methodology to
resolve the problem of the frequent
disconnections in mobile clients like Pocket PC,
in the context of Web pages visualization.
Keywords: Pocket PC, Hoarding, Transcoding,
Mobile clients, Wireless networks, PDA.
1. Introducción
En la actualidad, gracias a los grandes
descubrimientos en ciencia y tecnología, es
posible que las personas puedan entre otras
cosas, comunicarse y compartir información
entre sí en cualquier momento, a toda hora y en
todo lugar. A esto se le ha denominado cómputo
penetrante (pervasive computing). Uno de los
avances tecnológicos que ha hecho posible todo
esto es, sin duda, los dispositivos móviles.
Los dispositivos móviles son hoy en día muy
diversos, entre los que destacan los teléfonos
inteligentes (smart phones), los asistentes
personales digitales (PDA ), las computadoras
portátiles, las computadoras de mano (handheld)
o de bolsillo (Pocket PC), así como los sistemas
integrados (embedded systems) tales como
terminales de punto de venta, cajeros
automáticos, etc. Dichos equipos se han vuelto
muy populares debido principalmente a que su
costo disminuye día con día, mientras que su
poder de procesamiento aumenta
vertiginosamente. Entre las características
principales de estos dispositivos se encuentran
dos: su reducido tamaño y su conectividad con
otros equipos. La conectividad se logra
mediante el uso de redes inalámbricas.
Los dispositivos móviles presentan el problema
de frecuentes desconexiones, la cual se presenta
de manera más atenuada en este tipo de
arquitectura que en una plataforma de cómputo
convencional. Este problema genera, entre otras
cosas, que se pierda información o que no se
pueda realizar algún proceso como es debido
[1]. Además, este tipo de nuevas tecnologías
presentan dificultades en la forma en como se
presenta la información a los usuarios, debido
principalmente a las limitaciones de las
pantallas de despliegue y al limitado poder de
procesamiento (comparado con equipos
convencionales.
La tendencia más generalizada en nuestros días
es que los equipos móviles converjan junto a las
plataformas convencionales en una sola; es
decir, en un futuro no muy lejano, se espera que
no exista mucha diferencia entre estas
arquitecturas. Internet está jugando un papel
muy importante en este menester, actuando
como catalizador para lograr la convergencia.
2 Marco conceptual
Para el buen entendimiento de este artículo, es
necesario explicar algunos conceptos que
aclaren básicamente las siguientes preguntas:
¿Qué es acaparamiento? ¿En qué consiste la
transcodificación de contenidos Web? ¿Qué es
un dispositivo Pocket PC?
2.1 Acaparamiento
El acaparamiento (hoarding) se puede definir
como el proceso de replicación y procesamiento
en desconexión de datos previamente
seleccionados y copiados localmente en el
cliente móvil [2].

2. El acaparamiento surge del hecho de que las
desconexiones, tanto planeadas como
accidentales, no están consideradas en las
arquitecturas tradicionales, en particular con la
arquitectura cliente/servidor.
En informática, el concepto de acaparamiento es
un proceso integral, el cual incluye las etapas de
acaparamiento de datos, desconexión y
reintegración.
2.1.1 Estado de acaparamiento de datos
Los recursos requeridos para las operaciones
son precargados en la unidad móvil. La
reubicación de los datos es simple, debido a que
los datos son inaccesibles para otros sitios y
para otros nodos.
Para predecir las desconexiones de los equipos
móviles, se deben acaparar los recursos
periódicamente para poder trabajar en modo
desconexión. La pregunta medular en esta fase
consiste en ¿cómo anticipar las necesidades
futuras de los usuarios móviles? Una alternativa
consiste en que los usuarios especifican
explícitamente los datos que quieren; otra
alternativa es de manera implícita, la cual
consiste en examinar el historial de acceso a los
datos por parte del usuario, para tratar de
predecir de manera más óptima los recursos a
acaparar.
2.1.2 Estado de desconexión
En este estado, las aplicaciones usan solamente
los datos disponibles de manera local. La
petición de los recursos se puede realizar
insertado dichas peticiones en una cola para ser
atendida a la brevedad, cuando ocurra un evento
de reconexión.
2.1.3 Estado de reintegración
En esta etapa se debe responder a las siguientes
interrogantes:
1. ¿Cuál debe ser la unidad de acaparamiento:
bloques de archivos, archivos, grupos de
archivos o directorios?
2. ¿Cuándo se debe acaparar? La respuesta es:
cuando se necesita la información (i.e., cuando
la información es crítica).
3. ¿Qué recursos se deben acaparar? En esta
pregunta existe una gran diversidad de
respuestas; por ejemplo, se deben acaparar los
recursos de mayor prioridad, los recursos
definidos por el usuario, o los recursos más
accedidos.
4. ¿Cómo acaparar? Esta pregunta es
sumamente difícil de contestar, debido a que
existen diversas metodologías de solución, las
cuales resuelven problemas específicos.
2.1.4 Acaparamiento de sitios Web
Una de las características más preponderantes
que tienen las páginas Web, es que son más
usadas para la visualización que para las
actualizaciones, por lo que este hecho conlleva
un nuevo replanteamiento de la metodología de
acaparamiento, en este caso se debe determinar
¿qué páginas se deben acaparar?
Para soportar operaciones en modo
desconexión, la política de acaparamiento debe
ser extendida para cargar todos los documentos
de páginas previamente visitadas por el usuario
o anticipar las páginas que pueden ser visitadas
por el usuario.
Otro de los retos a resolver con respecto al
acaparamiento de páginas Web consiste en la
persistencia de la caché, la cual es crítica
durante las frecuentes desconexiones de los
equipos móviles. El acaparamiento no se puede
dar con la falta o ausencia de la caché.
En resumen, el esquema de acaparamiento
consta de los siguientes pasos:
1. Identificación de patrones de acceso.
2. Selección de los recursos que serán
replicados.
3. Control de reintegración de réplicas.
2.2 Transcodificador de contenidos Web
Por transcodificación (transcoding) se entiende
el proceso de convertir un formato o código a
otro, con la finalidad de que este nuevo formato
o código se adapte a la plataforma indicada para
su correcta visualización [3].
El mecanismo de transformación o
transcodificación de contenidos Web, lleva a
cabo una reorganización y agrupación de los
elementos contenidos en la página Web
solicitada, y de acuerdo a la delimitación del
lenguaje de entrada (HTML ), dicho mecanismo
se aplica sólo a un subconjunto del universo de
documentos que se encuentran en Internet[4].
Como resultado final de la transcodificación, se
obtienen páginas Web cuyo formato de
presentación o visualización es óptimo para un

3. dispositivo de despliegue limitado, tratando de
respetar fielmente la semántica original del
documento o página.
2.3 Pocket PC
El objetivo de este apartado es dar una idea
general sobre el tema, por lo que no
profundizamos en términos técnicos referentes a
la electrónica de estos dispositivos.
2.3.1 Historia
El primer antecedente de lo que ahora
conocemos como Pocket PC (PPC), fue el
Newton de la compañía Apple desarrollado en
1993; sin embargo, fue un fracaso total, debido
en parte a sus altos costos y a que la tecnología
para estos dispositivos aún se encontraba en
pañales.
En 1996 surge la Palm Pilot, la cual se
convertiría en un éxito total, llamando la
atención del mercado y convirtiéndose en el
primer PDA en ser popular. Por las mismas
fechas, y como respuesta de Microsoft por tener
una parte del negocio de los dispositivos
móviles, aparece Windows CE. Dicho sistema
operativo portó la mayoría de las bibliotecas de
Windows de 32 bits para hacerlo lo más
compatible posible permitiendo a los usuarios
realizar las mismas acciones que en su PC de
escritorio.
Es hasta el año 2000 cuando aparece la versión
3.0 de Windows CE y con ella la plataforma
Pocket PC. Si bien Windows CE 3.0 es el
sistema operativo, la palabra Pocket PC (PPC)
designa dispositivos con ciertas características
impuestas por Microsoft a los fabricantes para
sus dispositivos.
En el 2002 surge la plataforma Pocket PC 2002
(PPC 2002), que aunque bien se basa en
Windows CE 3.0 toma algunas ideas de
Windows CE .NET.
En el 2003, Microsoft evoluciona su concepto
de cómputo móvil y presenta la plataforma
Windows Mobile, que tiende a agrupar tanto a
dispositivos PPC 2003 como teléfonos
inteligentes. La versión más actual de esta
arquitectura recibe el nombre de Windows
Mobile 2003 Second Edition, la cual tiene como
sistema operativo Windows CE 4.2.
Se acaba de anunciar la nueva versión de la
plataforma Pocket PC cuyo nombre será
Windows Mobile 5, el cual se lanzará a finales
de este año. Su característica principal será el
fuerte reconocimiento de voz para la mayoría de
las acciones del sistema.
2.3.2 Características
Entre las principales características de estos
dispositivos se encuentran:
• Funcionalidad PIM (Personal Information
Manager), lo que en español conocemos como
Organizador electrónico, el cual, lejos de ser
una simple agenda electrónica, incluye
herramientas de gestión de información personal
tales como la posibilidad de enviar correos
electrónicos, programar tareas y notas.
• Poseen algún tipo de conectividad, es decir,
cuentan con algún tipo de Interfaz de red,
actualmente la gran mayoría posee interfaces de
red inalámbrica del tipo WiFi (IEEE 802.11)
y/o Bluetooth (IEEE 802.15).
• Tienen despliegue de pantallas muy limitados.
Por ejemplo, la resolución debe ser de 240x320
píxeles, deben contar con pantallas a color con
por lo menos 16 colores, capacidad de
iluminación de la pantalla, pantalla táctil
(sensible al tacto).
• Deben contar con un dispositivo señalador de
tipo pluma, conector de audífonos, micrófono
integrado, bocinas, puerto externo (serial o
USB) de sincronización, ranura para tarjetas de
expansión (PCMCIA, Compact Flash, SD, etc.),
además de baterías recargables.
• Baja capacidad de procesamiento de datos, en
comparación con arquitecturas tradicionales,
pero dichos procesadores se encuentran
optimizados para las tareas que realizan.
• Cuentan con memoria limitada tanto de
almacenamiento primario como secundario,
generalmente las memorias son del tipo
FlashROM las cuales permiten grabar y borrar
datos de manera permanente. Aquí tanto la
RAM como la ROM sirven para almacenar
datos como programas, esto debido a que,
mientras tenga energía la batería, alimentará la
memoria RAM evitando la pérdida de
información.
2.3.3 Procesadores
Las PPC presentan una arquitectura abierta, por
lo que se ha utilizado hardware muy diverso en
su construcción; en particular a lo referente a
sus microprocesadores, de los cuales se tienen
varios y que es necesario describirlos
brevemente [5] y [6].

4. 2.3.3.1 Familia ARM
El primer microprocesador para PPC y el más
popular, fue el ARM (Advanced RISC
Machines), el cual fue diseñado y
manufacturado por Acorn Computer Group a
mediados de los 80s.
El ARM es un microprocesador CMOS de 32
bits diseñado en arquitectura RISC , lo cual
significa que tiene un reducido conjunto de
instrucciones en comparación con arquitecturas
CISC como x86 (familia de microprocesadores
de Intel) o m68k (familia de microprocesadores
de Motorola).
StrongARM, resultado del trabajo de ARM Ltd.
y Digital, usa el conjunto de instrucciones de los
procesadores ARM, pero el cual es construido
con los chips de bajo costo de las series Alpha.
Digital vendió su manufacturación de chips a
Intel Corporation. La famosa iPaq (la PPC más
vendida) de Compaq (ahora HP) utiliza este
microprocesador. La iPaq es la PPC donde más
esfuerzo se ha realizado para tratar de portar
Linux al mundo de las PPC; de hecho,
actualmente existen versiones muy estables de
Linux como los proyectos Pocket Linux, iPaq
Linux, Opie, Familiar, entre otros.
Xscale es un microcroprocesador del tipo RISC
SIMD (Single Instruction Multiple Data). Este
chip es fabricado por Intel, por lo que
actualmente su uso está creciendo
enormemente.
Con la aparición de Windows Mobile 2003,
Microsoft ha determinado que dejará de ofrecer
su sistema operativo Windows CE para PPC
para microprocesadores que no sean
descendientes de la familia ARM. Esto debido
principalmente a dos razones: la primera,
referente a la dificultad de mantener códigos
diferentes de distintos microprocesadores y
segunda, porque ARM está dominando y según
Microsoft dominará el mercado de PPC por
muchas años más, gracias a la participación
activa de Intel.
2.3.3.2 Familia MIPS
MIPS es un microprocesador del tipo VLSI
RISC de 32 bits desarrollado por la compañía
japonesa NEC, que cuenta entre sus
características principales que permite
entubamiento y cuenta con un software
reorganizador de códigos, que entre otras cosas,
permite un mayor rendimiento. Cada instrucción
en promedio es realizada en dos ciclos de reloj.
Este tipo de microprocesadores son muy usados
en ambientes de servidores, estaciones de
trabajo y mainframes. Desde su diseño se trató
de portar toda la funcionalidad y robustez con
que cuentan estos microprocesadores al
ambiente móvil.
La PPC más venida en Japón, la Cassiopedia de
la compañía Casio utiliza este microprocesador.
2.3.3.3 Familia SH
SH3 es desarrollado por la compañía japonesa
Hitachi, pertenece a la familia de
microprocesadores Super H (Hitachi), los cuales
son microprocesadores de 32 bits con
instrucciones de 16 bits.
Entre las características principales de un
microprocesador SH3 podemos destacar las
siguientes: su diminuto tamaño y su bajo
consumo de energía, lo cual lo hacen ideal para
sistemas de cómputo móviles o sistemas
multimedia.
La ahora extinta, PPC Jornada de la compañía
HP utilizaba este tipo de microprocesador.
Actualmente, están disponibles en el mercado
las mejoras de este procesador llamadas SH4 y
SH5.
3. Descripción del problema
La Web es uno de los servicios más utilizados
de la Internet, motivo por el cual su
funcionamiento es crítico en muchos entornos
de nuestra sociedad.
Los equipos móviles están propensos a
constantes desconexiones y, por otra parte, la
Web por naturaleza, requiere de una conexión
permanente para poder operar. Por este motivo,
es necesario un mecanismo para poder hacer
accesible los recursos de un sitio Web sin
necesidad de conexión.
Por otra parte, debido a las limitantes de los
dispositivos móviles, los sitios Web no pueden
ser visualizados correctamente en esta clase de
dispositivos, razón por la cual se requiere de un
mecanismo para poder visualizar correctamente
las páginas Web en un dispositivo móvil con
despliegue limitado.
El nivel de complejidad que se identifica en el
desarrollo de aplicaciones para plataforma PPC
es sumamente alto, el problema fundamental es
el siguiente: Se pueden encontrar dispositivos
PPC con diferentes microprocesadores (e.g.

5. ARM, SH3, MIPS, etc.); para cada
microprocesador se debe desarrollar una
aplicación, lo que conlleva a la transportabilidad
del código fuente para crear código ejecutable
para cada plataforma, lo cual implica la
existencia de un compilador para cada
microprocesador.
En este apartado, se debe tener en cuenta que la
diversidad de microprocesadores puede llevar a
cambios en la forma de implementar algunas
funciones o instrucciones; sin embargo, la
lógica del programa no cambia por que la
implementación de nuestro agente intermediario
se hará en lenguajes de alto nivel, en contraste
con un lenguaje de bajo nivel (ensamblador),
donde cada programa es dependiente de la
arquitectura (un programa para un tipo de
microprocesador es único para ese tipo de
microprocesador).
Otro de los problemas de mayor complejidad
que presenta este proyecto, consiste en el
manejo del acaparamiento de sitios Web
transcodificados en un dispositivo PPC, debido
principalmente a los siguientes subproblemas:
1. Los mecanismos de replicación o precarga
están muy orientados a base de datos y memoria
caché, y prácticamente no existen mecanismos
que permitan el acaparamiento de recursos
informáticos, en especial con sitios Web y en
particular con los dispositivos móviles PPC.
2. La mayor problemática que presenta el
acaparamiento consiste en el control de las
réplicas tanto de manera local como del lado del
servidor, es por ello que se necesita un módulo
o mecanismo controlador que gestione la
negociación de dichas réplicas de tal forma que
sea automatizado y transparente para el usuario.
3. Otros de los factores a considerar en cuanto a
la cuestión del acaparamiento es el tamaño de
los recursos, debido a las limitantes de
almacenamiento impuestas a los dispositivos
PPC, esto hace necesario que exista un
mecanismo que controle el tamaño máximo de
los recursos a acaparar, el tipo de archivos a
acaparar, el tamaño máximo destinado al
acaparamiento en general, el directorio local de
almacenamiento, por mencionar algunas
restricciones
Tanto el manejo de eventos de conexión cómo
de reconexión, no están pensados en una
arquitectura cliente servidor tradicional, ya que
el modelo cliente/servidor en clientes móviles
esta inmerso en un ambiente de continuas
desconexiones, se hace necesario de un
mecanismo que controle y administre los
eventos de desconexión. Esto con lleva a un
cambio de paradigmas en la forma de realizar
software de red, se debe tener presente que las
desconexiones ocurren de forma más frecuente
que en otro tipo de plataformas.
3.1 Objetivo del proyecto
El objetivo general de este proyecto consiste en
diseñar e implementar un prototipo de agente
intermediario para plataforma Pocket PC 2000,
que gestione el acaparamiento de páginas Web
transcodificadas cuando se presenten eventos de
desconexión.
4. Antecedentes del proyecto
Este proyecto de tesis forma parte de la
arquitectura del proyecto “Moviware” [7].
La finalidad de Moviware consiste en dar
soporte a clientes móviles inalámbricos que
operan en un ambiente de red inestable, sujetos
a experimentar diversos fenómenos mientras se
encuentran trabajando.
Es una plataforma prototipo que se compone de
los siguientes módulos:
1. Gestor (“broker”) de desconexión y
reconexión. Este componente se encarga de
gestionar y procesar los eventos de desconexión
que se puedan presentar de manera voluntaria
(si el cliente lo solicita explícitamente) o
involuntaria (sin previo aviso).
2. Generador de patrones de acceso a sitios Web
basado en algoritmos de minería de reglas de
asociación. Estos componentes extraen patrones
de acceso en base a mecanismos de minería de
datos. Los patrones generados son clasificados y
colocados en un contenedor para su posterior
recuperación en base a criterios de selección que
el gestor de acaparamiento determina.
3. Gestor de acaparamiento de recursos
informáticos. Tiene la función de interpretar el
perfil de conducta de los usuarios móviles para
poder identificar el patrón de acceso que
permita la precarga de los recursos informáticos
que el patrón indique. También proporciona los
servicios para el procesamiento de los recursos
acaparados en modo de desconexión.
4. Gestor de contenidos Web. Este componente
se encarga de devolver recursos Web a
dispositivos móviles, atendiendo a las
características particulares de esos dispositivos.
La arquitectura de MoviWare es la siguiente:

6. Intermediario
Patrones
Gestor de Cache
de Acaparamiento
Recurso
Acaparado
Historial
De
Accesos
Minero
Encapsulador de
patrón
Identificador de
Patrón
Cliente Móvil
Inalámbrico
Gestor Local de
Acaparamiento
Gestor de
Acaparamiento
Clasificador de
Patrones
Aplicación
(Netscape, Explorer,
Pocket IE
Transcodificador
de contenidos Web
Identificador
De perfil de dispositivo
Generador de
Patrones
Generador de
árbol Patrón
Analizador de
Página HTML
Generador de página
Web
Transcodificada
Gestor de
Desconexión
Gestor de
Desconexión
HTTP
HTTP
FTP
FTP
Proxy Cache Squid
Cache
transcodificada
Cache
Gestor de
caches
Intranet
IEEE802.11
Intermediario
Patrones
Gestor de Cache
de Acaparamiento
Recurso
Acaparado
Historial
De
Accesos
Minero
Encapsulador de
patrón
Identificador de
Patrón
Cliente Móvil
Inalámbrico
Gestor Local de
Acaparamiento
Gestor de
Acaparamiento
Clasificador de
Patrones
Aplicación
(Netscape, Explorer,
Pocket IE
Transcodificador
de contenidos Web
Identificador
De perfil de dispositivo
Generador de
Patrones
Generador de
árbol Patrón
Analizador de
Página HTML
Generador de página
Web
Transcodificada
Gestor de
Desconexión
Gestor de
Desconexión
HTTP
HTTP
FTP
FTP
Gestor de
Desconexión
Gestor de
Desconexión
HTTP
HTTP
FTP
FTP
Proxy Cache Squid
Cache
transcodificada
Cache
Gestor de
caches
Intranet
IEEE802.11
Figura 1. Arquitectura Moviware.
En el óvalo con línea continua, se muestra la
parte fundamental en donde se centrará este
proyecto. En el óvalo con línea punteada en
círculos, se muestra el origen de donde nuestro
proyecto sacará el acaparamiento de los datos.
Para finalizar, en óvalos con líneas punteadas en
cuadrados, se muestran los módulos con los que
interacciona nuestro proyecto y que es necesario
integrar y/o adaptar para su correcto
funcionamiento en esta plataforma.
5. Trabajos relacionados
Aunque existen muchos trabajos relacionados
con el acaparamiento, éstos se enfocan a base de
datos (replicación) y memoria (precarga), por lo
que el abanico de trabajos relaciones disminuye
considerable.
En [8] se plantea una metodología (la cual
servirá de base para replantear nuestra propia
metodología) para realizar acaparamiento en
dispositivos móviles, desgraciadamente estos
dispositivos móviles comprenden plataformas
convencionales (laptops y computadoras de
escritorios) con interfaces de red inalámbricas.
Otra deficiencia que presente este trabajo,
consiste en que no realiza transcodificación de
contenidos Web.
En [2] se muestra la base para realizar el
acaparamiento; es decir, mediante algoritmos de
minería de uso Web aplicados a bitácoras de
servidores Web, encuentra un conjunto de
Reglas de asociación que permiten predecir los
posibles recursos que el usuario podría
necesitar; dichas reglas se guardan en un
contenedor de patrones, y es de aquí de donde
nuestro proyecto va partir para realizar el
acaparamiento.
Esta aplicación no realiza acaparamiento, es
decir, por si sola no tiene una aplicación final
visible a los usuarios. Actualmente se está
realizando un trabajo de tesis dentro del cenidet
que pretende mejorar la funcionalidad de este
trabajo.
En [4] se propone una metodología (la cual se
tiene contemplada integrar en este trabajo de
tesis) para realizar la transcodificación de
páginas Web, desgraciadamente no realiza
acaparamiento de estas páginas ya
transcodificadas y aunque está enfocada para
dispositivos PPC, no se realiza ningún
procesamiento (programación) en éste. El
trabajo de transcodificación se realiza en un
intermediario que se encuentra del lado del
servidor, el cual pertenece a un equipo de
cómputo tradicional.

7. En [9] se presenta un middleware para
dispositivos móviles que gestiona diversos
recursos cuando se presentan eventos de
desconexión, en este sentido este trabajo tiene
una gran similitud con nuestro tema de tesis, la
primera diferencia fundamental consiste en el
área que se cubre. En nuestro tema de tesis el
enfoque es de manera general para cualquier
sitio (con sus respectivas limitantes), mientras
que en este trabajo relacionado, se enfoca hacia
una aplicación de aprendizaje móvil (M-
Learning) denominada m-Eldit (versión móvil
del programa de e-Learning ‘Eldit’ ).
Otro aspecto muy similar de este proyecto con
el nuestro, consiste en que este trabajo
relacionado realiza acaparamiento basado en el
seguimiento (tracking) del usuario, es decir, la
predicción de los recursos a acaparar se realiza
de manera más sencilla, debido a que deduce los
posibles recursos a acaparar en base a los
recursos faltantes que tiene que completar dicho
usuario; es decir, el acaparamiento se realiza de
manera especial para cada usuario, mientras que
en nuestro tema de tesis el acaparamiento se
realiza de manera general para todos los
usuarios. Para dejar más claro esto, supongamos
que el usuario X ha tomado los temas uno, dos y
cinco de un curso de 6 lecciones, por lo que lo
más probable es que a futuro, el usuario ocupe
los cursos tres, cuatro y seis.
Mientras que en un sitio Web, determinar que
recursos se deben acaparar a los usuarios es más
complejos, ya que las preferencias de los
usuarios son extremadamente variantes.
Este trabajo de tesis utiliza y propone una
metodología de acaparamiento que está
enfocada hacia dispositivos PPC; también
realiza un tipo especial de transcodificación,
dicha transformación se realiza de forma
personalizada gracias a que se cuenta con el
perfil del usuario. La personalización realizada
en este trabajo, consiste simplemente en el
cambio de parámetros a visualizar, como son los
colores de la interfaz, el tamaño de las letras
etc.; mientras que en nuestro trabajo la
transcodificación se realiza de manera genérica
de todos los sitios Web.
6. Metodología de la solución
El esquema de solución que se propone consiste
en una adaptación del esquema cliente/servidor
orientada a clientes móviles, este modelo consta
tanto de clientes móviles, como de un servidor
encargado de brindar servicios de recursos Web;
en medio de nuestros clientes y servicios se
encuentra nuestra capa de intermediarios, tanto
del lado del cliente como del lado del servidor,
el modelo general propuesto puede visualizarse
en la figura 2.
MIPS
SH3
ARMARM
GAP
SQUID
GAS
Internet
Servidores Web
GAS=Gestor de Acaparamiento del
Servidor
GAP=Gestor de Acaparamiento Pocket
Figura 2. Esquema general de la arquitectura propuesta.
La arquitectura propuesta (ver figura tres)
consta de manera general de dos partes, la
primera parte del lado del dispositivo cliente
móvil PPC, del otro lado, se muestra el
mecanismo del lado del servidor. Entre estas
dos partes, se encuentra la interfaz de red
inalámbrica (en nuestro caso IEEE 802.11).

8. Del lado cliente, se encuentran dos partes
claramente diferenciadas, la primera es la
aplicación final al usuario, en nuestro caso, el
navegador (e.g. Pocket Internet Explorer u
otros.) que solicita recursos Web.
Por el otro, se encuentra el intermediario que se
va a desarrollar, en nuestro caso lo hemos
denominado GAP (Gestor de Acaparamiento
Pocket). Dicho intermediario consta de los
siguientes componentes:
Navegador (IPE, Netscape)Navegador (IPE, Netscape)
GAP
Cliente Pocket PC
WiFi
¿Conexión?
¿Caché?
T
Caché transcodificada
Sí
No
No Error
Sí
Conversión
local / Web
Analizador
HTTP
GAS
W
Internet
Squid
¿Transcodificada?
Transcodificador
¿Actual?
Acaparador
T
Caché transcodificada
Sincronizador
Caché servidor
Sincronizador
Caché local
Sí
Sí
No
No
Éxito
G
D
L
GAL
MT
MA
Observador
Gestor de
Desconexión
Módulos a integrar pertenecientes a Moviware
Figura 3. Arquitectura propuesta.
1. Observador.- También llamado vigía, su
objetivo fundamental es revisar y procesar las
peticiones tanto de entrada como de salida que
van o vienen dirigidas a la aplicación
(navegador Web).
2. Gestor de Desconexión (GDL).- Tiene la
función de revisar el medio físico de conexión y
determinar si el cliente se encuentra conectado o
no.
3. Gestor de Acaparamiento Local (GAL).-
Cuya misión consiste fundamentalmente en dos
cosas:
a. Revisar si existe un recurso acaparado, en
caso de existir se manda el recurso solicitado
(en este caso el Observador debe de cambiar el
encabezado para hacer creer al navegador que la
solicitud viene del exterior); en caso de no
existir el recurso acaparado, se manda un
mensaje de error, el observador deberá construir
una página Web con un mensaje de error que el
usuario visualizará.
b. Controlar la sincronización de la caché
transcodificada local con la caché del Servidor.
Del lado del servidor, encontramos dos
elementos principales: el servidor Proxy caché
Squid, encargado de obtener los recursos Web
solicitados; y el intermediario del lado del
servidor, el cual hemos denominado GAS
(Gestor de Acaparamiento del Servidor), esta
arquitectura consta de los siguientes elementos:
1. Mecanismo Transcodificador (MT).- Es el
encargado de transcodificar (transformar una
página Web para su correcta visualización en un
dispositivo de despliegue limitado) los recursos
Web obtenidos del servidor Squid. (Este módulo
es parte de Moviware y se le harán las

9. modificaciones pertinentes a fin de integrarlo en
este trabajo de tesis).
2. Analizador HTTP.- Es el encargado de
analizar el contenido del encabezado HTTP de
la solicitud del cliente, en este caso nos interesa
encontrar información como el recurso
solicitado, el tipo de cliente que realiza la
petición (sistema operativo, tipo de
microprocesador), la fecha de modificación del
recurso solicitado, entre otros campos. Este
analizador es similar a un módulo identificador
de dispositivo.
3. Mecanismo Acaparador (MA).- Se encarga
de dos funciones básicas, acaparar un sitio Web
transcodificado y sincronización de la caché
transcodificada, para esta última opción debe
haber un control de versiones entre la caché
local y la caché del servidor (este módulo existe
en Moviware pero en la versión sin
transcodificar, la intención es integrar este
módulo y el intermediario que se desarrollará,
de tal forma que detecte el dispositivo desde el
cual se está realizando una petición de un
recurso Web y se envié el recurso
transcodificado o no).
4. Gestor de desconexión (GD).- Es el
encargado de revisar el medio inalámbrico y,
procesar todas las peticiones realizadas por el
cliente que no pudieron ser atendidas, cuando se
presentó el evento de desconexión.
En lo referente a herramientas a utilizar, aun no
se han definido las herramientas definitiva de
desarrollo, actualmente, nos encontramos en una
fase de investigación en cuanto a herramientas y
entornos de programación se refiere; como
posibles alternativas se tienen el uso de
herramientas como el Microsoft eMbedded
Tools (eMbedded Visual Basic y eMbedded
Visual C++), Visual Studio .NET (Visual Basic
.NET y Visual C#), así como analizar algunas
variantes de Java (se deben tener máquinas
virtuales especiales para PPC), como es el caso
J2ME (Java 2 Micro Edition), Personal Java y
Embedded Java.
7. Conclusiones
Este trabajo de investigación se encuentra en su
primera etapa, por lo que hasta este momento no
se cuentan con resultados relevantes. Entre los
beneficios que se desean obtener de este trabajo
se encuentran:
1. Visualización de páginas Web en modo de
desconexión en dispositivos PPC, de manera
transparente para el usuario.
2. Agilizar los tiempos de acceso a las páginas
Web, al tener un sitio Web acaparado de manera
local, cuando se presenten desconexiones.
3. Visualización de páginas Web de manera
adecuada, de tal forma que su visualización no
dependa de las limitantes de su pantalla.
4. La facilidad de administración y, por ende de
programación, al no tener páginas distintas para
distintas plataformas.
5. Ahorro de energía en dispositivos que
dependen de un suministro finito, esto como
consecuencia de trabajar en modo de
desconexión.
6. Ahorro en tiempo aire, si es que el dispositivo
se conecta a través de una línea de conexión
celular (e.g. GSM/GPRS).
Entre las limitantes que presenta este trabajo se
encuentran las siguientes:
1. El GAP sólo se implementará para plataforma
PPC 2000 (no se garantiza que trabaje sobre
otras plataformas de PPC como PPC 2002 o
Windows Mobile 2003).
2. Los microprocesadores para los cuales se
generará código ejecutable del GAP son: SH3,
ARM y MIPS (tampoco se garantiza que corra
sobre arquitecturas de microprocesadores más
modernos).
3. El acaparamiento en el GAP estará limitado a
las características propias del PPC (definiremos
un sistema con características mínimas para
realizar el acaparamiento).
4. El GAS se limitará a los servicios
proporcionados por la arquitectura Moviware
(no pretendemos en principio realizar
modificaciones a las funcionalidad de cada
módulo a integrar, es decir, los módulos a
integrar se quedarán con sus alcances y
limitaciones respectivos, simplemente se
realizarán modificaciones para lograr su
coordinación).
8. Referencias bibliográficas
[1] Alarcón Gálvez Fernando, “Mecanismo para
Gestión de Conexión en Sistemas
Cliente/Servidor Móviles”, tesis de maestría,
cenidet, agosto de 2002.
[2] Valenzuela Molina David R., “Mecanismo
para Predicción de Acaparamiento de Datos
en Sistemas Cliente/Servidor Móviles”, tesis
de maestría, cenidet, agosto de 2002.

10. [3] Chanchaem Thong, “A Survey on Internet
Content Transcoding for Universal Access”,
Department of Computer Science, Kent
State University, mayo de 2003.
[4] Uriarte Cabada Claudia Selene.
“Transformador de Contenidos Web para
Asistentes Personales Digitales”, tesis de
maestría, cenidet, julio de 2004.
[5] Clark David, “Mobile processors begin to
grow up”, revista IEEE Computer, pp. 22-
25, marzo de 2002.
[6] Hattori Toshihiro, et al., “Design
Methodology of a 200MHz superscalar
microprocessor: SH-4” Hitachi, Ltd., Tokio,
Japón. 249 IEEE Proceedings of the 35th
Design Automation Conference (DAC’98)
0-89791-964-5/98.
[7] González Serna Juan Gabriel. “Plataforma
middleware reflexiva para aplicaciones de
cómputo móvil en Internet (Movirware)”,
Centro Nacional de Investigación y
Desarrollo Tecnológico (CENIDET), de
septiembre de 2001 a agosto de 2003,
financiamiento COSNET: 570.01-P.
[8] Verduzco Reyes Gustavo, “Gestor de
Acaparamiento de Patrones de Sitios Web en
Clientes Móviles”, tesis de maestría,
cenidet, agosto de 2003.
[9] Trifonova Anna, “Hoarding Content in M-
Learning Context”, tesis doctoral en
desarrollo, Universidad de Trento, Italia,
2004.
Juan Carlos Olivares Rojas
Ingeniero en Sistemas
Computacionales egresado
del Instituto Tecnológico de
Morelia en 2004. Es
estudiante de la especialidad
de sistemas distribuidos en
la Maestría en Ciencias en
Ciencias Computacionales
en el Centro Nacional de Investigación y
Desarrollo Tecnológico (CENIDET). Sus áreas
de interés son el cómputo móvil, redes de
computadoras, sistemas de telecomunicaciones
y base de datos Actualmente es vicepresidente
de la rama estudiantil de la IEEE del CENIDET.
Juan Gabriel González Serna
Ingeniero en Sistemas
Computacionales por el
InstitutoTecnológico de
Acapulco (ITA) en 1992 y
Maestro en Ciencias en
Ciencias de la Computación
por el cenidet en 1995.
Profesor Investigador del
Departamento de Ciencias Computacionales del
cenidet en el área de Sistemas Distribuidos
desde 1995 a la fecha.Candidato a Doctor en
Ciencias de la Computación por el CIC del IPN.
Sus áreas de interés son: Redes inalámbricas
(802.11x y Bluetooth), Minería de uso de la
Web y Sistemas Distribuidos.
Azucena Montes Rendón
Licenciada en Matemáticas
por parte de la Universidad
Autónoma Metropolitana en
1994. Realizo Maestría en
Matemáticas e informática
aplicada así como Doctorado
en Matemáticas en la
Université de Paris-
Sorbonne en Francia, en 1998 y 2002. Sus áreas
de interés son: Tratamiento informático del
lenguaje natural, formalización de la semántica
y de la sintaxis.Topología y quasi-topologias.
Lógica.