El documento describe una arquitectura propuesta para una caché que almacena sitios web en dispositivos móviles Pocket PC. La caché utilizaría un agente intermediario que almacena contenido de sitios web que han sido transformados y adaptados a la plataforma Pocket PC, para permitir el acceso a los sitios cuando haya desconexiones. Esto solucionaría el problema de visualización de sitios web en dispositivos móviles cuando ocurren eventos de desconexión, aprovechando la capacidad de almacenamiento en caché local

1. Arquitectura de una caché para almacenar sitios Web en
dispositivos móviles Pocket PC
Juan Gabriel González Serna1,2
, Azucena Montes Rendón1
, Víctor Jesús Sosa Sosa1
, y Juan
Carlos Olivares Rojas1
{gabriel, amr, vjsosa, jcolivares04c}@cenidet.edu.mx
1
Centro Nacional de Investigación y Desarrollo Tecnológico (CENIDET)
Cuernavaca, Morelos, México
2
Centro de Investigación en Computación (CIC-IPN) México D.F.
RESUMEN
El presente trabajo pretende “poner la Web en los
bolsillos de los usuarios”. Para logar esta
afirmación se requiere de un enorme esfuerzo
debido a una gran variedad de factores que están
de manera inherente en los dispositivos móviles,
tal es el caso de las frecuentes desconexiones, las
limitantes en los mecanismos de despliegue y de
introducción de la información, las limitantes de
almacenamiento, entre otras. Este trabajo presenta
una alternativa para solucionar el problema de la
visualización de sitios Web en dispositivos
móviles cuando se presenten eventos de
desconexión; para ello, se utiliza un agente
intermediario que guarda en una caché el
contenido de sitios Web que han sido
transformados y adaptados a la plataforma Pocket
PC.
Palabras claves: caché, Pocket PC, acaparamiento,
transcodificación, Proxy.
1 INTRODUCCIÓN
Debido a la gran cantidad de información y la
importancia de ésta en la vida moderna, se ha
hecho necesario disponer de los datos en cualquier
momento y en todo lugar. Esto se ha logrado
gracias a la aparición y popularización de los
dispositivos móviles, tal es el caso de los
dispositivos PDAs como las Pocket PC (PPC) y
más recientemente los teléfonos inteligentes.
Estos dispositivos se han popularizado debido a su
diminuto tamaño y a su gran versatilidad para
adaptarse a las nuevas necesidades de los
usuarios. Dichos dispositivos han dejado de ser
simples juguetes electrónicos que permiten
gestionar la información personal de los usuarios
para convertirse en verdaderas computadoras que
caben en el bolsillo de los usuarios.
Desafortunadamente, estos dispositivos carecen de
ciertas funcionalidades que han frenado su
progreso ascendente a los consumidores finales.
Su principal característica se ha convertido en su
principal deficiencia: su tamaño. Debido a su
tamaño, y sobretodo a que los recursos de la Web
no se crearon tomando en cuesta a esta clase de
dispositivos, el uso de recursos Web no ha sido el
adecuado para los usuarios. Esto ha llevado a que
no se obtenga todo el potencial de esta plataforma.
Los eventos de desconexión son frecuentes en este
tipo de dispositivos, por lo que la mayoría de las
aplicaciones orientadas a conexión se verían
afectadas seriamente, tal es el caso de la Web que
necesita un enlace persistente y orientado a
conexión.
El acaparamiento consiste en el proceso de
replicación y procesamiento en desconexión de
datos previamente seleccionados y copiados
localmente en el cliente móvil [1]. Para determinar
que recursos de Web son necesarios acaparar, es
necesario basarnos en un proceso de minería de
datos sobre bitácoras de servidores Web que nos
determinen patrones interesantes. Los patrones
están en forma de reglas de asociación, los cuales
nos indican la probabilidad de que si se visita un
recurso Web sean accedidos otros recursos. Esto
nos da mayor ventaja que si se utilizan simples
estadísticas [2].

2. Para solucionar el problema de la limitaciones de
pantallas, se propone un esquema de conversión
de recursos Web; en este caso páginas a un
documento Web transformando y formateado para
ajustarse al dispositivo cliente. En la mayoría de
los casos se realiza una transcodificación, la cual
consiste en convertir un documento html a un
subconjunto del mismo destilando todas aquellas
características como tablas, frames que no están
del todo estandarizadas en los dispositivos
móviles [3].
Para solucionar estos problemas se propone una
arquitectura o estructura de una caché de recursos
Web en esta clase de dispositivos móviles.
2 ALMACENAMIENTO DE DATOS
EN DISPOSITIVOS POCKET PCs
La forma en como se almacena la información, así
como los métodos de acceso e indexación de los
recursos, determina en gran medida el desempeño
de un sistema operativo y de los medios de
almacenamiento.
Los dispositivos PPC almacenan la información
en un esquema de almacenamiento primario y
secundario. En el almacenamiento primario no
existe una clara diferencia entre memoria RAM y
ROM como en las plataformas de cómputo
tradicional.
Gracias al avance de las nuevas tecnologías es
posible almacenar datos en memorias de tipo
ROM, está nueva tecnología recibe el nombre de
Memorias Flash ya que utilizan un conjunto de
circuitos integrados que pueden cambiar su estado
a través de cierto voltaje.
La memoria RAM juega un doble papel en esta
clase de dispositivos: almacena datos temporales
(volátiles) así como puede albergar programas del
usuario.
La RAM según [4] se divide en tres partes: el
Object Store (almacena datos y aplicaciones del
usuario), el Registry (Registro del sistema
operativo) y el Heap (montículo: zona de
memoria utilizada para datos dinámicos como
pueden ser listas, pilas, colas, etc.).
El almacenamiento en memoria RAM se puede
considerar semi-persistente ya que debido a la
naturaleza propia, los dispositivos PPC nunca se
apagan de manera general, sino que hibernan (se
encuentran en estado de espera) con el objetivo de
ahorrar energía. Cuando la batería se acaba los
datos de los usuarios se pierden, es por este
motivo que la mayoría de los dispositivos PPC
cuentan con una batería de respaldo que dura en
algunos casos pocas horas como medida de
protección ante la pérdida de la energía de la
batería.
Gracias a que los datos en una memoria ROM se
pueden modificar actualmente sin mucho
problema, se ha logrado implementar sistemas de
archivos persistentes en PPC, permitiendo que los
datos no se pierdan. De esta forma es posible
actualizar el sistema operativo dependiendo del
fabricante, como es el caso de HP que en algunos
de sus modelos permite actualizar gratuitamente el
sistema operativo. También se pueden adoptar
otras alternativas como el proyecto Familiar [5]
que implementa una versión del kernel de Linux
para dispositivos PPC iPAQ.
Una de las mayores limitaciones de los
dispositivos móviles corresponde al tamaño de los
medios de almacenamiento tanto primario como
secundarios. Las memorias basadas en tecnologías
Flash ROM son relativamente caras comparadas
con otros medios como los magnéticos y ópticos,
aunque afortunadamente su precio disminuye día
con día.
Debido a que los PDAs han dejado de ser simples
asistentes digitales, la información que manejan a
crecido considerablemente. Esto ha llevado a que
se necesiten de espacios de almacenamiento
muchos mayores. La solución ha sido
implementar dispositivos de almacenamiento
secundario de bajo costo como es el caso de las
tarjetas multimedia como: Secure Digital (SD),
MultiMedia Card (MMC), Memory Stick (MS) de
Sony y Compact Flash (CF) entre otros. El
principal problema que presentan estos
dispositivos es la ausencia de un estándar, por lo
que los dispositivos PPC tienen una ranura de
expansión distinta dependiendo del fabricante.
Gracias a estos medidos de almacenamiento
secundario ha sido posible el desarrollo de
aplicaciones de gestión de datos, ya que ha sido
posible implementar sistemas gestores de base de
datos como SQL Server CE (ahora SQL Mobile),
OracleLite, entre otros (ver Figura 1).

3. Figura 1. SQL Server CE 2.0
En lo referente a la estructura de los archivos
utilizados en PPC, éstos son totalmente
compatibles (en estructura) con Windows para
plataformas PCs. Se utiliza el sistema de archivos
FAT, por lo que se carece de un esquema
confiable de seguridad (gestión de contraseñas y
usuarios).
3 TIPOS DE RECURSOS A
ACAPARAR
Para poder diseñar un buen sistema de caché,
como en cualquier otra aplicación, es de vital
importancia conocer el flujo de información; en
nuestro caso recursos que se almacenarán y
procesarán.
Un sitio Web puede conceptualizarse como un
grafo arborescente donde el conjunto de páginas
corresponde a los nodos del grafo; mientras que
las aristas están representadas por los enlaces
(hipervínculos) entre las páginas. El nodo inicial
corresponde con la página principal del sitio,
generalmente index.html (pudiendo ser otra).
Los documentos de Web (HTML) pueden verse
como contenedores de otros documentos, como
pueden ser imágenes, secuencias de audio y video,
entre otros. Debido a este hecho, los archivos
HTML son indispensables en la caché local ya
que a partir de ellos se podrán obtener los demás
recursos.
En un principio la Web consistía básicamente en
un servidor de archivos, donde los clientes
solicitaban recursos de hipertexto. Poco a poco,
surgieron diversos tipos de recursos por lo que fue
necesario definirlos y estandarizarlos, esto se
logró a través de las extensiones MIME.
Si bien es cierto que MIME (Multimedia Internet
Mail Extension, por sus siglas en inglés) apareció
hace algunos años con el correo electrónico, es
hasta la llegada de la Web cuando tomó la
importancia con la que actualmente goza.
Para un navegador Web, las respuestas del
servidor son vistas como un flujo de bytes a través
de la red, lo cual implica que se deba saber el
formato que tiene para procesarlo adecuadamente.
Por esta razón, a través de un encabezado HTTP
se puede definir el tipo de aplicación para que el
navegador lo pueda interpretar adecuadamente.
En un principio los navegadores Web soportaban
un parser distinto para cada tipo de aplicación.
Como el crecimiento de la Web ha sido
exponencial, este esquema pronto se volvió
obsoleto por lo que surgió el concepto de
agregados (plug-ins). Los agregados, son
pequeñas aplicaciones que se incrustan en el
navegador y que proveen cierta funcionalidad
específica. Cuando un navegador Web procesa el
encabezado, verifica el tipo MIME y si se trata de
una aplicación conocida la procesa de manera
directa o indirecta a través de un plug-in. Si se
desconoce la aplicación, simplemente se descarga
el recurso.
Además, en la plataforma PPC se están utilizando
aplicaciones como Word, Excel, PowerPonit,
Access y Outlook. Dichos documentos tienen un
formato especial que ayuda a conservar el espacio
de almacenamiento. Existe una correspondencia o
compatibilidad entre las versiones de Office y
Pocket Office. Dicha compatibilidad se logra
convirtiendo los documentos de un formato a otro,
tal y como se muestra en la Tabla 1.
Aplicación PC PPC
Access *.mdb *.cdb
Mapa de bits *.bmp *.2bp
Word *.doc *.psw
Excel *.xls *.pxl
PowerPoint *.ppt *.ppv
Tabla 1. Conversiones de archivos más
comunes en PPC.

4. Con esta conversión se logra ahorrar mucho
espacio, por lo que el sistema de caché propuesto
en este documento pretende realizar una
conversión en línea al momento de almacenar un
recurso en la caché. Esta conversión se pretende
lograr a través de la invocación de las APIs
disponibles en la interfaz de Windows CE
Services que implementa ActiveSync.
Los tipos MIME más utilizado en dispositivos
móviles según [6] son los siguientes:
Formato Formatos MIME
WML Text/vnd.wap.wml
Text/xml
WMLScript Text/vnd.wap.wmlscript
HTML Text/html
cHTML Text/html
XHTML Application/xhtml+xml
Text/xml
GIF Image/gif
JPEG Image/jpg
WBMP Image/vnd.wap.wbmp
PNG Image/png
Image/vnd.wap.png
MPEG Video/mpeg
Video/mpeg4generic
Windows
Media Video
Video/x-ms-wmv
Real video Video/vnd.rn-realvideo
MP3 Audio/mp3
Audio/x-mp3
MIDI Audio/midi
Windows
Media Audio
Audio/x-ms-wma
Real Audio Audio/vnd.rn-realaudio
Archivo de
instalación
de Windows
Application/cab
Cascading
Style Sheets
Text/css
Contacto de
Agenda
Text/x-vcard
Contacto de
Calendario
Text/x-vcalendar
Tabla 2. Tipos MIME para dispositivos
móviles.
Como se puede apreciar, los tipos MIME de los
dispositivos móviles son muy similares a los de
plataformas convencionales. En este sentido, la
utilización de un tipo MIME en un dispositivo
móvil corresponde a si se tiene la aplicación
correspondiente para interpretar dicho recurso.
Es por está razón, que el filtro, para saber que
tipos de archivos se deben almacenar en la caché
caerá sobre el usuario, pudiendo éste determinar
que recursos se guardan en base a las aplicaciones
que él dispone.
4 ARQUITECTURA DE LA CACHÉ
PROPUESTA
Para plantear esta propuesta, se observó la forma
en como guardan la caché algunos navegadores.
Por ejemplo, el navegador Netscape (ahora
conocido como Mozilla) permite indicar que no
exista la caché; mientras que Pocket Internet
Explorer no lo permite, la caché debe existir.
El navegador más utilizado en dispositivos PPC
corresponde al Pocket Internet Explorer, el cual
esta disponible de facto en todos los dispositivos
PPC. Realizar la caché directamente sobe la
estructura de la caché traería como consecuencia
que cualquier usuario que utilizase un navegador
diferente al PIE no pudiera utilizar nuestro
prototipo. Por esta razón, se decidió que el sistema
de caché se realizaría sobre un directorio diferente
al realizado por PIE.
El historial en PIE se almacena en un directorio
específico del sistema, el cual generalmente es
(/Windows/Profiles/Guest). En este directorio se
encuentran tres directorios correspondientes a
Cookies, History y Temporary Internet Files. En
estos directorios se guardan los archivos visitados
en una caché. El esquema de está caché puede
visualizarse en la Figura 2.
A través de una pequeña investigación se pudo
determinar que el sistema de caché está
estructurado en base a un índice, representado por
el archivo index, el cual no se puede visualizar ya
que se trata de un archivo binario. Dicho archivo
hace referencia a carpetas que tienen un nombre
aleatorio y que contienen los recursos visitados.
Este esquema de carpetas aleatorias puede verse
en sistemas de Proxys caché como Squid [7]. En
este esquema los recursos se almacenan en una
carpeta determinada, por lo que sólo se registra en
un índice la ubicación de dicho recurso.
El esquema anterior es útil cuando se visitan
páginas que no están muy relacionadas entre sí,
como puede ser el caso de recursos en sitios
distintos o peticiones realizadas por diversos
clientes. Este esquema no puede ser utilizado para
nuestra aplicación debido a que todos los recursos

5. de un sitio Web se almacenan en un mismo
directorio, si se almacenarán siguiendo el esquema
anterior, el acceso a los recursos se vería
ralentizado.
Figura 2. Estructura de la caché en PIE.
En el esquema que se propone, se mantiene una
lista que contiene el conjunto de todos los
recursos contenidos en el patrón de un sitio Web.
Para determinar que elementos contendrá dicha
lista, nos basamos en el esquema que propone
Internet Explorer de utilizar nombre del archivo,
URL, tipo, tamaño, caduca, última modificación,
último acceso y última comprobación. Por lo que
nuestra lista contendrá los campos de URL y ruta
física. Se determinó no usar por el momento el
esquema de tiempo de caducidad y de última
visita, debido a que la reintegración de contenidos
Web no es fácil de implementar en un esquema de
acaparamiento. A continuación se muestra un
ejemplo de una lista de patrones que se está
utilizando:
<?xml version="1.0" encoding="UTF-8" ?>
<cache>
<peticion sitio="http://www.cenidet.edu.mx/"
patron="cenidet.xml" fecha="10/10/2005"/>
<peticion sitio="http://www.itmorelia.edu.mx/"
patron="itmorelia.xml" fecha="10/10/2005"/>
</cache>
Para la implementación de la lista, se
contemplaron varias opciones, como es el caso de
utilizar un archivo binario, una base de datos o un
archivo XML.
Se determinó utilizar un archivo en XML dado
que se tiene la ventaja de que se pueden agilizar
las búsquedas. Su defecto consiste en que es un
archivo de texto plano que puede ser fácilmente
modificable.
Si se utilizara un archivo en formato binario en
lugar de uno de texto plano, se evitarían
problemas de seguridad y de que puedan
modificarse la información contenida en la lista.
Su desventaja radica en que para realizar la
búsqueda se vuelve un poco complicada si es que
se tienen muchos archivos.
Si se utilizara una base de datos, se tendría la
ventaja de que la búsqueda se realizaría de manera
transparente al programador, ya que éste no tiene
que implementar algún algoritmo de búsqueda. Su
desventaja radica en el hecho de que consume una
cantidad considerable de almacenamiento y de que
no todos los dispositivos cuentan con una base de
datos.
En lo referente a la estructura de archivos que
debe poseer el sistema caché se tomó como base
el sistema de archivos Joliete, ampliamente
utilizado en los sistemas de archivos para CDs.
Las características con las que cuentan este
sistema se encuentran que ningún archivo se
encuentre anidado en un máximo de 7
subdirectorios así como limita el tamaño del
nombre del archivo a un máximo de 106
caracteres.
En base a lo anterior, se tomó la decisión de no
limitar el tamaño de la profundidad del sitio Web
debido a que no existe un estándar en la
elaboración de un sitio Web, lo que con lleva a
que puedan existir sitios que se encuentren muy
anidados. Además, no se tomó en cuenta está
consideración como parámetro de configuración,
debido fundamentalmente a que el proceso de
acaparamiento excluye la selección de niveles por
parte del usuario, ya que el acaparamiento
encuentro el número ideal de niveles en base a las
reglas de asociación generadas por los elementos.
El esquema de un archivo índice de recursos
acaparados de un sitio de Web
(http://www.cenidet.edu.mx/) se muestra a
continuación:
<?xml version="1.0" encoding="UTF-8" ?>

6. <recursos>
<acaparado nombre="/index.html"
ubicacion="index.html" />
<acaparado nombre="/css/general.css"
ubicacion="general.css" />
<acaparado nombre="/img/mecatronica.gif"
ubicacion="mecatronica.jpg" />
</recursos>
El servicio de gestión de la caché se ejecuta en
modo línea de comandos; es decir, un demonio o
servicio en segundo plano. Se debe hacer mención
que aunque no existe shell en modo texto en
plataforma PPC, se pueden ejecutar estas
aplicaciones sin ningún problema. Como
comentario adicional, el sistema se está
implementado en C# por ser por muchas razones
el lenguaje de programación con mayores
características para la plataforma PPC [8].
Este trabajo forma parte de una investigación cuyo
propósito consiste en implementar un Gestor de
Acaparamiento de Sitios Web Transcodificados
(GASWT) para plataforma PPC [9]. Éste a su vez,
forma parte una arquitectura más completa
denominada Moviware [10] cuyo objetivo es
brindar una serie de servicios a equipos móviles
propensos a desconexiones.
El modelo general de la arquitectura GASWT se
puede observar en la Figura 3. En lo pertinente
al sistema de caché, los módulos que tienen que
ver con la arquitectura propuesta son:
Gestor de Acaparamiento Local (GAL): Revisa si
existe un recurso acaparado. En caso de existir, se
manda el recurso solicitado al navegador local. En
caso de no existir el recurso acaparado, se
mandará un mensaje de error. Se deberá construir
una página Web con un mensaje de error que el
usuario visualizará. Otra de su función consiste en
controlar la sincronización de la caché
transcodificada local con la caché del Servidor.
Mecanismo Acaparador (MA). Se encarga de dos
funciones: acaparar un sitio Web transcodificado
y sincronizar la caché transcodificada, Para esta
última opción, debe haber un control de los
recursos que ya sean acaparado con anterioridad.
Navegador (IPE, Netscape )Navegador (PIE)
GAP
Cliente Pocket PC
Redes Inalámbricas (WiFi, Bluetooth)
¿Conexión?
¿Caché?
T caché
Sí
No
No
Error
Sí
recurso
Analizador
HTTP
GAT
W
Internet
Squid
¿
¿Transcodificada?
?
Transcodificador
¿Actual?
Acaparador
T
Caché
Sincronizador
caché servidor
Sincronizador
caché local
Sí
Sí
No
No
Patrón
G
D
L
GAL
MT
MA
Observador
Gestor de
Desconexión
Módulos a integrar pertenecientes a Moviware
Petición Respuesta
Recurso
Revisar
estado
de la
conexión
Fecha
Página
transcodificada
Arquitectura GASWT
Descomprime
Comprime
Envió de nuevos patrones,
actualización de patrones existentes
Navegador (IPE, Netscape )Navegador (PIE)
GAP
Cliente Pocket PC
Redes Inalámbricas (WiFi, Bluetooth)
¿Conexión?
¿Caché?
T caché
Sí
No
No
Error
Sí
recurso
Analizador
HTTP
GAT
W
Internet
Squid
¿
¿Transcodificada?
?
Transcodificador
¿Actual?
Acaparador
T
Caché
Sincronizador
caché servidor
Sincronizador
caché local
Sí
Sí
No
No
Patrón
G
D
L
GAL
MT
MA
Observador
Gestor de
Desconexión
Módulos a integrar pertenecientes a Moviware
Navegador (IPE, Netscape )Navegador (PIE)
GAP
Cliente Pocket PC
Redes Inalámbricas (WiFi, Bluetooth)
¿Conexión?
¿Caché?
T caché
Sí
No
No
Error
Sí
recurso
Analizador
HTTP
GAT
W
Internet
Squid
¿
¿Transcodificada?
?
Transcodificador
¿Actual?
Acaparador
T
Caché
Sincronizador
caché servidor
Sincronizador
caché local
Sí
Sí
No
No
Patrón
G
D
L
GAL
MT
MA
Observador
Gestor de
Desconexión
Módulos a integrar pertenecientes a Moviware
Petición Respuesta
Recurso
Revisar
estado
de la
conexión
Fecha
Página
transcodificada
Arquitectura GASWT
Descomprime
Comprime
Envió de nuevos patrones,
actualización de patrones existentes
Figura 3. Arquitectura del sistema propuesto.
El esquema básico del funcionamiento de
la caché se muestra a continuación:

7. Figura 4. Diagrama de actividades del proceso
de acaparamiento.
5 CONCLUSIONES
A lo largo de este documento se mostró el
esquema de gestión de la caché local en
dispositivos PPC que actualmente se está
desarrollando. Los resultados obtenidos de está
investigación son los siguientes:
1. El usuario determinará el límite de espacio de
la caché por lo que deberá contar con una
tarjeta de almacenamiento secundario.
2. Se realizará, de ser posible, una conversión
entre los formatos de archivo conocidos para
ahorrar espacio.
3. El usuario será el que discrimine que recursos
Web se acapararán en base a las aplicaciones
con las que cuente.
4. El sistema de caché será construido desde
cero y no dependerá de ningún tipo de
navegador.
5. El sistema de caché es indexado, desarrollado
a través de XML.
6. La estructura del sistema de archivos será
idéntica a la del sitio Web eliminado sólo
aquellos recursos que no caen sobre el patrón.
7. Los parámetros de configuración del sistema
caché serán establecidos a través de una
interfaz gráfica.
6 TRABAJOS FUTUROS
Como actividades que se realizarán en el futuro
inmediato, se destaca la investigación de la
viabilidad del sistema de caché en dispositivos
Smartphone con Windows Mobile.
7 AGRADECIMIENTOS
Al CoSNET por el apoyo otorgado para la
realización de este proyecto de investigación a
través de la beca 102004189 PJ para estudios de
maestría.
REFERENCIAS
[1] 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.
[2] Hernández Méndez Gabriel. “Generador de
patrones de navegación de usuarios aplicando
Web log mining”, tesis de maestría en
desarrollo, cenidet, septiembre de 2005.
[3] Uriarte Cabada Claudia Selene.
“Transformador de Contenidos Web para
Asistentes Personales Digitales”, tesis de
maestría, cenidet, julio de 2004.
[4] Kelvin Hilton CE00343-2 SDMCA
”Working With Data”
www.soc.staffs.ac.uk/~cmtkch/ (Última
consulta: septiembre 2005)
[5] Proyecto Familiar.
http://familiar.handheld.org/ (Última consulta:
septiembre 2005).
[6] Firtman, Maximiliano. ”Desarrollos móviles
con .NET”. Primera edición. Buenos aires. MP
Ediciones, 2005. 368 pp.
[7] Servidor Proxy-caché Squid.
http://www.squid-cache.org/ Última consulta
septiembre 2005.
[8] González Serna Gabriel, Montes Rendón
Azucena, Olivares Rojas Juan Carlos.
“Comparativa y evaluación de las
herramientas de programación para
desarrollar aplicaciones en plataforma Pocket
PC”. Por aparecer en el 6to. Congreso
Internacional de las Ciencias
Computacionales. Colima, Colima, México,
del 27 al 30 de septiembre de 2005.
[9] Olivares Rojas, Juan Carlos, “Gestor de
Acaparamiento de Sitios Web
Transcodificados para Plataforma Pocket PC”,
tesis de maestría en desarrollo, cenidet,
diciembre de 2005.
[10] González Serna Juan Gabriel. “Plataforma
middleware reflexiva para aplicaciones de
cómputo móvil en Internet (Movirware)”,

8. Centro Nacional de Investigación y Desarrollo
Tecnológico (cenidet), de septiembre de 2001
a agosto de 2003, financiamiento COSNET:
570.01-P.
CURRÍCULUM
Juan Gabriel González
Serna es Ingeniero en
Sistemas Computacionales por
el Instituto Tecnoló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 es
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, Web semántica e
inteligencia artificial.
Víctor Jesús Sosa Sosa es
Doctor en Ciencias de la
Computación por la
Universidad Politécnica de
Cataluña (UPC-Barcelona,
España) en convenio con el
Centro de Investigación en
Computación del IPN. Es
Vicepresidente de la Asociación Nacional de
Investigación en Ciencias Computacionales
(ANICC) desde Octubre 2002 a la fecha.
Sus áreas de interés son: Sistemas distribuidos,
Programación en el Web, Bases de datos y
Sistemas operativos.
Juan Carlos Olivares Rojas
Es Ingeniero en Sistemas
Computacionales por el
Instituto Tecnológico de
Morelia. Actualmente realiza
postgrado de Maestría en
Ciencias en Ciencias de la
Computación en la especialidad de Sistemas
Distribuidos en el Centro Nacional de
Investigación y Desarrollo Tecnológico
(CENIDET). También es vicepresidente de la
rama estudiantil del CENIDET-IEEE. Sus áreas
de interés son el cómputo móvil, redes de
telecomunicaciones y base de datos.