Reporte1

Reporte de actividades en el período
septiembre - diciembre de 2005 de la tesis
titulada:
“Gestor de Acaparamiento de Sitios Web
Transcodificados para Plataforma Pocket
PC”
Presenta:
Ing. Juan Carlos Olivares Rojas
Director:
M.C. Juan Gabriel González Serna
Codirector:
Dra. Azucena Montes Rendón
Cuernavaca, Morelos, México, a 2 de
diciembre de 2005.
Para mayor información consultar la documentación anexa

i
Tabla de contenido
1 PANORAMA GENERAL DEL PROYECTO DE TESIS..........................................................................................1
2 CRONOGRAMA DE ACTIVIDADES ........................................................................................................................2
3 EVALUACIÓN DE HERRAMIENTAS.......................................................................................................................2
4 ANÁLISIS DE LOS RECURSOS A ACAPARAR ....................................................................................................4
5 ESTUDIO DE LA HERRAMIENTA SELECCIONADA...........................................................................................4
6 ESTUDIO DE MOVIWARE ........................................................................................................................................5
7 DISEÑO E IMPLEMENTACIÓN DEL GAP.............................................................................................................7
7.1 PRUEBAS ................................................................................................................................................................14
8 OTRAS ACTIVIDADES.............................................................................................................................................17
8.1 MODELO GENERAL DE SOLUCIÓN Y ARQUITECTURA PROPUESTA.................................................................................17
8.2 JUSTIFICACIÓN .......................................................................................................................................................19
8.3 ACAPARAMIENTO.....................................................................................................................................................21
8.4 ESTADO DEL ARTE ................................................................................................................................................21
8.5 MÁS ACTIVIDADES...................................................................................................................................................22
8.6 PUBLICACIONES ......................................................................................................................................................23
9 ACTIVIDADES A REALIZAR PARA EL SIGUIENTE PERÍODO.....................................................................23
10 REFERENCIAS.......................................................................................................................................................24
Figuras
Figura 1. Cronograma de actividades del primer cuatrimestre. ___________________________________________2
Figura 2. Análisis general del problema a resolver. ________________________________________________________7
Figura 3. Diagrama de caso de uso sin considerar errores._______________________________________________8
Figura 4. Diagrama de interacción detallada del prototipo._______________________________________________9
Figura 5. Diagrama de clases del módulo GAP._________________________________________________________9
Figura 6. Definición de la clase GAP___________________________________________________________________10
Figura 7. Especificación de la clase Observador. _________________________________________________________11
Figura 8. Diagrama de clases del Gestor de Desconexión Local. _____________________________________________12
Figura 9. Diagrama de clases del GAL._________________________________________________________________12
Figura 10. Diagrama de clases de la Configuración. ______________________________________________________13
Figura 11. Definición de la clase archivoXML. ___________________________________________________________13
Figura 12. Prototipo del módulo de configuración del sistema. __________________________________________15
Figura 13. Manejo de desconexiones en el GAP._______________________________________________________16
Figura 14. Prueba de un recurso acaparado con conexión existente. __________________________________________16
Figura 15. Visualización de un recurso acaparado en modo desconexión. ______________________________________17
Figura 16. Modelo general de solución. ______________________________________________________________18
Figura 17. Arquitectura propuesta. __________________________________________________________________19
Figura 18. Justificación del desarrollo del prototipo en dispositivos PDA.______________________________________20
Tablas
Tabla 1. Comparativa de ventas de equipos PDA por sistema operativo. _______________________________________20

ii
Tabla 2. Comparativa entre los conceptos de replicación, acaparamiento, precarga y caching. _____________________21
Tabla 3. Estado del arte propuesto. ____________________________________________________________________22
Tabla 4. Cronograma de actividades enero-abril de 2006. __________________________________________________23

1
1 Panorama general del proyecto de tesis
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 a causa de 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
visualización de recursos Web que requiere de una conexión persistente libre de errores de
transmisión y por otra parte, el contenido de estos recursos no toma en cuanta las limitantes
de esta clase de dispositivos sobre todo en cuestión de espacio de almacenamiento y
restricciones de las pantallas. Para solucionar estos problemas se propone sistema que
gestione el acaparamiento de sitios Web transcodificados cuyo contenido se adapte a las
limitantes de los dispositivos móviles PPC.
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 [Val02]. Para
determinar que recursos 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 [Hen05].
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 [Uri04].

2
2 Cronograma de actividades
A continuación se muestra el cronograma de actividades para este período y se detallan cada
una de las actividades realizadas. Se considera un avance del 35% en el desarrollo de la
tesis.
SEPT OCT NOV DIC
# Concepto 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
1 Evaluación de herramientas
Embedded Visual Tools
Visual Studio .Net
Java 2 Micro Edition
Otras herramientas de programación
Comparativas de las herramientas
2 Análisis de los recursos a acaparar
Tamaño
Tipo de recursos
Estructura de almacenamiento
Documentación
3 Estudio herramienta seleccionada
4 Estudio de Moviware
Acaparador
Contenedor de Patrones
Transcodificador
Gestor de desconexión
Documentación
5 Diseño e implementación del GAP X X
Observador
Primera presentación cuatrimestral
Gestor de Desconexión Local X X
Figura 1. Cronograma de actividades del primer cuatrimestre.
3 Evaluación de herramientas
Se evaluaron las siguientes herramientas y entornos de programación:
> eMbedded Visual Tools
o eMbedded Visual C++
o eMbedded Visual Basic
> Visual Studio .Net
o C#
o Visual Basic .NET
> Java 2 Micro Edition
100%
100%
100%
70%
100%

3
> Otras herramientas de programación
o Microsoft Mobile Internet Toolkit (MMIT) ahora Mobile ASP .NET
o Webmatrix.
o Mono.
o Microsoft Platform Builder.
o Emulador de DOS (aplicaciones legadas)
o Herramientas de software libre.
Finalmente, se realizó una comparativa de dichas herramientas para determinar cual de estas
es la mejor para nuestro proyecto de tesis:
Se determinó que .NET CF con lenguaje en C# es en estos momentos la mejor herramienta
de programación para plataforma PPC. Está herramientas nos permite desarrollar de manera
fácil y sencilla aplicaciones potentes que pueden correr en múltiples plataformas no sólo de
PPC sino de otros dispositivos móviles y convencionales.
Nuestra segunda opción corresponde eVC++ la cual se descartó por la complejidad del
lenguaje en sí, ya que para generar el código para distintos microprocesadores es necesario
tomar algunas consideraciones. Se recomienda su uso cuando se desee obtener mayor
velocidad de ejecución de las aplicaciones y/o un uso intensivo de hardware.
La tercera opción corresponde a la tecnología Java, la cual se descartó para nuestro futuro
proyecto debido a que no existen máquinas virtuales para todas las plataformas y dispositivos
PPC, además de que estas máquinas virtuales no son gratuitas. Se recomienda su uso cuando
se tiene software legado que se quiere ejecutar en plataforma PPC.
Como cuarta opción se tiene el desarrollo de aplicaciones en plataforma Linux, se descartó
dicha opción por el hecho de que no es posible instalar Linux en todo tipo de dispositivo PPC,
además de que el complejo de instar el sistema operativo y las herramientas de
programación es sumamente complejo. Se recomienda su uso cuando se quieran utilizar
lenguajes muy específicos en el desarrollo. Cuando se necesite realizar aplicaciones que
aprovechen las características multitarea y multiusuario que proporciona Linux.
La quinta opción corresponde a eVB, la cual se descartó por ser un lenguaje interpretado y
con pocas características. Se recomienda su uso cuando se desee realizar desarrollos rápidos
y sencillos.
Por último se descartó utilizar ASP .NET (y sus variantes) por ser una tecnología que no
permite realizar muchas cosas en el dispositivo móvil. Se recomienda su uso cuando el
procesamiento se realiza en mayor medida en el lado del servidor y en el cliente sólo se
implementará una interfaz a través del Web que se ajustará a cada tipo de dispositivo.
Esta actividad está terminada al 100% y se redactó y se expuso dicho tema en un Congreso
Internacional (ver anexo de Publicaciones).

4
4 Análisis de los recursos a acaparar
Otra de las actividades que se realizaron consistió en realizar un análisis de los recursos a
acaparar, tales como: tamaño, tipo de recursos, estructura de almacenamiento y su
respectiva documentación. En este apartado se han obtenido los siguientes resultados:
o El sistema de archivo de los dispositivos PPC es FAT por lo que es totalmente compatible
con dispositivos de cómputo tradicional.
o El almacenamiento de información se basa en tecnologías Flash ROM y RAM.
o El almacenamiento persistente está limitado pero puede ser resuelto rápidamente con
tecnologías que son relativamente baratas y de gran capacidad como: Compact Flash,
Secure Digital, Multimedia Card, Memory Stick, entre otras.
o Los recursos a acaparar dependerán de la selección que haga el usuario. Técnicamente es
posible ejecutar una multitud de aplicaciones en esta clase de dispositivos simplemente se
necesita tener el programa adecuado.
o Para la elección de los recursos a acaparar se escogió el estándar MIME (Multimedia
Internet Mail Extension) que define la mayoría de las aplicaciones utilizadas en la Web.
o En lo referente a la estructura de la caché, se determinó no limitar el número de
directorios del sitio Web; así como no limitar el tamaño en disco. El usuario determinará el
límite de espacio de la caché por lo que deberá contar con una tarjeta de almacenamiento
secundario.
o El sistema de caché será construido desde cero y no dependerá de ningún tipo de
navegador (aunque si bien es cierto que Pocket Internet Explorer domina el mercado).
o El sistema de caché será indexado y será desarrollado a través de XML.
o 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.
o Los parámetros de configuración del sistema caché serán establecidos a través de una
interfaz gráfica.
Esta actividad está terminada en un 100%.
5 Estudio de la herramienta seleccionada
La justificación de la presente actividad va de la mano en que es necesario tener
conocimiento previo de la herramientas a utilizar; en nuestro caso C#. Se leyó lectura

5
especializada, además de que nos enfocamos a programar directamente sobre el proyecto de
tesis.
C# es un lenguaje moderno y orientado a objetos, con una sintaxis muy similar a la de C++ y
Java. Combina la alta productividad de Visual Basic con el poder y la flexibilidad de C++.
La misma aplicación que se ejecuta bajo Windows podría funcionar en un dispositivo móvil de
tipo PDA. Con C# .NET no nos atamos a ninguna plataforma en particular.
C# gestiona automáticamente la memoria, y de este modo evita los problemas de
programación tan típicos en lenguajes como C o C++.
C# es un lenguaje que cumple con la especificación CLS. El código que crearemos con él será
traducido a instrucciones MSIL para entonces ser traducido, justo antes de su ejecución, a
instrucciones nativas que correspondan a la plataforma concreta sobre la cual estemos
trabajando.
El código MSIL generado a partir de la compilación de código C# es idéntico al código MSIL
generado a partir de cualquier otro lenguaje CLS.
Esta actividad está terminada al 100%, aunque como se sabe nunca se deja de aprender un
nuevo lenguaje.
6 Estudio de Moviware
Esta actividad se realizó en base a que es necesario comprender el entorno con el cual se va
a interactuar para poder realizar la adaptación y/o integración del software respectivo. Por
este motivo, se realizó un estudio a profundidad con los aspectos más relevantes de los
componentes de la arquitectura Moviware que a continuación se presenta.
En esta actividad se ejecutaron e instalaron los diversos mecanismos que componen la
arquitectura de Moviware
Del Gestor de Acaparamiento [Ver03] concluimos que de manera general realiza
acaparamiento en clientes móviles. Este trabajo tiene la problemática que con archivos de
gran tamaño no funciona adecuadamente, además de que no se realizan acaparamiento de
sitios Web dinámicos por la complejidad que ello representa. Otra limitante radica en que no
se realiza reintegración de contenido debido a que los archivos en la Web son casi
exclusivamente de sólo lectura.
El Generador de Patrones es el encargado de generar los patrones en base al histórico de
peticiones realizados por los clientes a un servidor Web. Este trabajo de tesis genera las
entradas para el trabajo de tesis que estamos realizando. Existen actualmente dos versiones
[Val02] y [Hen05], cada una con sus propias características, siendo la última la mejor; pero la
cual apenas acaba de ser liberada.

6
Dentro del intermediario del lado del servidor se encuentra el módulo transcodificador [Uri04],
el cual se estudia por que es necesario que el contenido de los recursos Web se adapte a las
limitantes de pantalla de los dispositivos móviles. Este modulo será integrado al trabajo de
tesis que se está realizando para poder brindar de dicha característica al producto final. El
mecanismo transcodificador se encarga de adaptar el contenido Web existe para que se
ajuste a la limitante de los dispositivos móviles.
Uno de los problemas principales que se presentan en los dispositivos móviles consiste en las
frecuentes desconexiones en la infraestructura de telecomunicación a la cual se ven
sometidos. Es por este motivo que se necesita de un mecanismo que gestione los eventos de
desconexión, por lo que es necesario estudiar la metodología que proporciona Moviware para
el control de las desconexiones. Este módulo de la arquitectura Moviware se compone
actualmente de dos elementos: el gestor de desconexión [Ala02] y el servidor Proxy cache
con soporte para desconexión [Jua05].
El objetivo del gestor de desconexión es desarrollar un sistema de gestión de desconexión y
reconexión para los usuarios de redes inalámbricas y de aplicaciones cliente/servidor que
permita a estos usuarios solicitar información a través de la Internet sin la necesidad de un
enlace permanente y libre de desconexiones.
Al terminar esta actividad se han pensado tres posibles alternativas para el análisis y diseño
de la solución al problema del GAT:
1. Desarrollar un middleware o intermediario entre el mecanismo acaparador y
transcodificador. Esta solución se piensa que no es la ideal dado que los dos sistemas
no se encuentran bien diseñados tanto en sus interfaces de entrada y salida. Por lo
que diseñar el mecanismo requiere de una gran complejidad en el paso de parámetros,
además de que existe actividades que se repiten en ambos sistemas, lo cual daría
como resultado un programa lento. Como ventaja se tiene el hecho de que el código
original no se tendría que modificar.
2. Desarrollo de un nuevo sistema copiando clases y adaptándolas para su correcta
integración. En este sentido se trataría de eliminar clases que tengan funcionalidades
similares. Se considera una buena opción ya que eliminaría redundancia de actividades
y traería como consecuencia un mejor producto. El problema es determinar que clases
eliminar y como integrar las clases seleccionadas para que trabajen juntas.
3. La última opción consiste en asimilar la funcionalidad de todas las clases de esta
solución y tratar de implementar una nueva versión construida desde cero que realice
el mecanismo de transcodificación y acaparamiento. El problema radica en que
consiste en realizar de nuevo lo creado pero tiene como ventaja que se tiene un
sistema sin necesidad de conocer totalmente a la perfección los mecanismos
anteriores. Esta se considera la última opción a elegir.
Esta actividad está concluida al 100%

7
7 Diseño e implementación del GAP
La presente actividad se enfoca en la construcción del prototipo del agente intermediario en
la plataforma PPC. De manera esquematizada, el problema atacar puede visualizar de la
forma indicada en la Figura 2.
Figura 2. Análisis general del problema a resolver.
Las operaciones básicas que se pueden realizar sobre el sistema son dos: visualización de
páginas o recurso de Web en desconexión y la visualización de recursos de Web en línea.
Ambas operaciones hacen uso del mecanismo de transcodificación, mientras que se utiliza el
acaparamiento cuando se presenta el caso de uso de visualización de recursos en modo
desconexión. Estas operaciones se pueden visualizar con el diagrama de casos de usos
mostrado en la Figura 3.

8
Figura 3. Diagrama de caso de uso sin considerar errores.
En la Figura 4, se muestra el esquema básico de interacción entre los principales
componentes del sistema.
El diagrama de clases del desarrollo en su parte del GAP, se muestra en la Figura 5. En dicho
diagrama se puede observar que la clase principal corresponde a GAP, la cual esta compuesta
de muchos objetos Observador y de un objeto Configuración, GAL y GDL. Tanto la clase GAL
y Configuración hacen uso de la clase XML para procesar archivos XML.

9
Figura 4. Diagrama de interacción detallada del prototipo.
Figura 5. Diagrama de clases del módulo GAP.
El objeto GAP es el programa principal (punto de entrada de la aplicación) su función consiste
en:

10
1. Leer el archivo de configuración del sistema
2. Aplicar la configuración
3. Crear manejador de desconexiones
4. Crear el sistema de caché en caso de no existir
5. Realizar de manera infinita la atención de peticiones (crear un objeto Observador y
ejecutarlo a través de un hilo).
La definición de la clase GAP se muestra en la Figura 6.
Figura 6. Definición de la clase GAP
El objetivo de la clase Observador consiste en brindar seguimiento a cada una de las
peticiones realizadas por el navegador para llevarlas a buen término. Sus funciones
principales son las siguientes:
1. Escuchar petición
2. Procesar encabezado (identificar dispositivo, etc.)
3. Verificar la existencia de un patrón en el sitio
4. Verificar la existencia del recurso en el patrón
5. Recuperar recurso de la caché
6. En cualquier otro caso tratar de obtener respuesta al GAT (Squid)
7. Obtener respuesta
8. En caso de desconexión y no encontrarse el recurso en la caché mostrar mensaje de
error.
9. Reenviar respuesta al navegador
La especificación de esta clase está definida en la Figura 7.

11
Figura 7. Especificación de la clase Observador.
Algunos de los problemas encontrados durante el desarrollo del observador son los
siguientes:
1. No se sabe a ciencia cierta cuando termina la respuesta.
2. Se utilizan buffer auxiliares y no todo el flujo.
3. Content-Length no está siempre definido.
4. No se controla las desconexiones
5. Posible implementación errónea en el PPC del método obtenerRecursoLinea() dado
que funciona correctamente en PC.
A través del Gestor de Desconexión Local, se controla la comunicación entre el cliente y el
servidor. La definición de esta clase está dada en el diagrama de la Figura 8.
Se encarga de controlar las desconexiones. La forma de implementación no es la adecuada
ya que satura la red. Es mejor implementar un mecanismo por agotamiento de tiempo
(timeout). Entre sus funciones principales están:
1. Crear un timer que ejecute un proceso de monitorización
2. Dicho proceso saca estadísticas de efectividad.
3. En base a las estadísticas determina en que estado se encuentra el sistema: online,
offline.

12
Figura 8. Diagrama de clases del Gestor de Desconexión Local.
Los problemas que se han encontrado durante la fase de implementación son los siguientes:
1. En un principio se tenía un ciclo infinito que saturaba enormemente la conexión.
2. Se estableció un tiempo de atención a 5 segundos.
3. Se tenía planeado considerar desconexiones planeadas pero esto es imposible dado el
esquema de interacción (el usuario sólo podría decidir estar conectado o no y el
sistema realmente no realizaría la conexión)
Esta actividad debería realizarse hasta el siguiente cuatrimestre, pero debido a que se
ocupaba en algunas porciones del código del GAP se ha implementado de manera parcial
(30% de la subactividad Gestor de Acaparamiento Local –GAL-).
El objetivo de este componente consiste en realizar la planificación y control de los recursos
de Web contenidos en la caché local con la misión de poder trabajar en modo de desconexión.
El diagrama de dicha clase se muestra en la Figura 9.
Figura 9. Diagrama de clases del GAL.

13
Su funcionalidad consiste en:
1. Manipular archivos en XML (verificar si existen, abrirlos, recuperar información,
escribir datos, etc.)
2. Recuperar un archivo de la caché y mostrarlo en el navegador.
La clase Configuración se encarga de leer el archivo XML indicado asignando los valores a los
respectivos componentes del sistema. La especificación de la clase puede observarse en la
figura Figura 10.
Figura 10. Diagrama de clases de la Configuración.
La clase archivoXML realiza el procesamiento de bajo nivel de archivos en XML; es decir,
realiza el parseo de un archivo XML de configuración. No se realiza una validación semántica
ya que no existen las clases para realizarlo en .NET CF (en .NET tradicional si se puede
realizar). El diagrama con la especificación de los métodos y propiedades de la clase se
muestra en la Figura 11.
Figura 11. Definición de la clase archivoXML.
El archivo de configuración del desarrollo de tesis tiene el siguiente formato:
<?xml version="1.0" encoding="UTF-8"?>
<GASWT>
<GAT ip="192.168.190.33" puerto="3128" />
<GAP ip="127.0.0.1" puerto="10800" cache="cache" indice="patrones.xml"/>
</GASWT>

14
En donde se indican las opciones principales para los dos subsistemas del GASWT: GAP y
GAT. Este archivo es una versión preliminar ya que aún faltan características a considerar
como el tipo de recursos a acapara, entre otros.
El archivo contenedor de patrones tiene el siguiente formato:
<?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.itcolima.edu.mx/" patron="itmorelia.xml"
fecha="10/10/2005"/>
…
</cache>
En donde cada petición tiene almacenado el nombre del sitio, el archivo contenedor de
patrones para dicho sitio y la fecha de última modificación. Este archivo también se encuentra
en versión borrador y pudiera cambiar en futuras implementaciones.
El archivo de recursos acaparados tiene el siguiente formato:
<?xml version="1.0" encoding="UTF-8" ?>
<recursos>
<acaparado nombre="/index.html" ubicacion="index.html" />
<acaparado nombre="/css/general.css" ubicacion="general.css" />
…
</recursos>
Cada recurso acaparado posee el nombre del recurso, así como la ubicación física del recurso
en el dispositivo móvil. También se trata de una versión parcial del archivo de recursos
acaparados.
Esta actividad se encuentra completa al 70% debido a que las subactividades Observador y
GSL se encuentran en un 80 y 70% (además se adelantó la subactividad GAL).
7.1 Pruebas
El prototipo en desarrollo se ha probado a parte de dispositivos Pocket PCs en dispositivos de
cómputo tradicional (PC) y emuladores de Pocket PC y SmartPhone con Windows Mobile.
En la Figura 12 en el lado izquierdo, se muestra la interfaz gráfica del módulo de
configuración del sistema, por el momento sólo se han llenado algunos datos básicos de
control del sistema. El objetivo de este módulo consiste en verificar que es posible escribir
archivos de configuración en formato XML, ya que el sistema lee la información de
configuración desde un archivo.

15
Se implementó dicho módulo debido a que editar un archivo de configuración en esta
plataforma (sobre todo en lo referente a los métodos de entrada y en especial en escribir es
algo molesto y tedioso).
La idea es terminar este módulo con todas las opciones de configuración disponibles. Se tiene
contemplado añadir nuevas funcionalidades a dicho módulo como la ejecución del servicio
GAP propiamente entre otras.
Figura 12. Prototipo del módulo de configuración del sistema.
Otra restricción de la Plataforma PPC consiste en que no es posible visualizar
simultáneamente dos aplicaciones al mismo tiempo (aunque si se permite ejecutarlas; es
decir, existe multitarea). Esto con lleva a que no se pueda a preciar con lujo de detalle los
mensajes del GAP (al menos en el proceso de prueba y depuración es importante ya que nos
permite visualizar el buen funcionamiento del sistema). Algunos fabricantes colocan
herramientas auxiliares que permiten intercambiar de manera fácil y sencilla entre
aplicaciones. Esto se aprecia en la misma figura pero del lado izquierdo.
En la Figura 13, también se muestra en su contraparte de la derecha, el mensaje de error
que se produce cuando no es posible recuperase de un evento de desconexión y el recurso
no existe en la caché. El mensaje es demasiado breve y sin diseño, se espera mejorarlo ya
que actualmente se cuenta con un método dentro del GAL que muestra un recurso acaparado
y disponible en la caché en el navegador.

16
Figura 13. Manejo de desconexiones en el GAP.
En la Figura 14, en la parte izquierda se muestra la visualización de un recurso de Web que se
encuentra acaparado en la caché. En la parte de la derecha de la misma figura, se muestra el
flujo de mensajes que se muestra en pantalla; en este caso, se encuentra un patrón para el
sitio, se verifica que existe el recurso solicitado en el patrón y se trata de obtener de la
ubicación física del dispositivo local; finalmente, se muestra el recurso solicitado y se queda
en espera constante de solicitudes o de procesarlas cuando se encuentra en línea.
Figura 14. Prueba de un recurso acaparado con conexión existente.
En la Figura 15, se muestra la visualización de un sitio Web acaparado sin conexión a la red.
La prueba consistió en acceder al sitio http://www.cenidet.edu.mx/ y tener acaparado
algunos recursos de dicho sitio, en este caso el recurso index.html, y algunas imágenes. En
dicha figura en su parte de la izquierda se muestra que algunas imágenes no se cargaron ya
que no se encuentran acaparados; también puede apreciarse que en lugar de mostrar los
logos de algunas carreras se muestran otras imágenes acaparadas en su lugar. Del lado

17
izquierdo de dicha figura simplemente se muestra el flujo de mensajes de depuración de las
peticiones de dicho sitio.
Figura 15. Visualización de un recurso acaparado en modo desconexión.
8 Otras actividades
Durante el período de actividades que se reporta en el presente documento, se realizaron
diversas actividades extras a las programadas en el cronograma de actividades de la
propuesta de este trabajo de tesis.
8.1 Modelo general de solución y arquitectura propuesta
La primera actividad realizada consistió en rediseñar el modelo conceptual de la arquitectura
propuesta en vista de que se apegue lo más que se pueda al objetivo principal de esta tesis,
el cual consiste en:
“diseñar e implementar un prototipo de servicio intermediario para plataforma Pocket PC
2000, que gestione el acaparamiento de páginas Web transcodificadas cuando se presenten
eventos de desconexión”.
El nuevo modelo general de la solución propuesta quedó de la forma mostrada en la Figura
16.

18
MIPS
SH3
ARMARM
GAP
SQUID
GAT
Internet
Servidores Web
GAT=Gestor de Acaparamiento y
Transcodificación
GAP=Gestor de Acaparamiento para los
dispositivos Pocket PC
Figura 16. Modelo general de solución.
En donde GAP representa el módulo principal a desarrollar y GAT resulta de la integración y/o
adaptación del mecanismo de acaparamiento en el servidor y del transcodificador de
contenidos Web presentes en la arquitectura Moviware de la cual este trabajo forma parte.
De estas consideraciones la arquitectura propuesta se modificó en algunos aspectos
quedando como se muestra en la Figura 17.

19
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
GAP
Cliente Pocket PC
¿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
GAP
Cliente Pocket PC
¿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
Petición Respuesta
Recurso
Revisar
estado
de la
conexión
Fecha
Página
transcodificada
Arquitectura GASWT
Descomprime
Comprime
GAP
Cliente Pocket PC
¿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
GAP
Cliente Pocket PC
¿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
Petición Respuesta
Recurso
Revisar
estado
de la
conexión
Fecha
Página
transcodificada
Arquitectura GASWT
Descomprime
Comprime
GAP
Cliente Pocket PC
¿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
GAP
Cliente Pocket PC
¿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
Petición Respuesta
Recurso
Revisar
estado
de la
conexión
Fecha
Página
transcodificada
Arquitectura GASWT
Descomprime
Comprime
Figura 17. Arquitectura propuesta.
8.2 Justificación
Otra de las actividades realizadas consistió en aumentar la justificación del por que
desarrollar una aplicación sobre un dispositivo PPC.
En la Figura 18, se muestra una clasificación de dispositivos móviles teniendo en cuenta su
movilidad (dado por el tamaño de los dispoitivos) así como su poder de comunicación y
procesamiento de datos. De la figura se puede observar que los dispositivos Pocket PC
(Palmsize o PDA) se encuentran en el punto medio de la clasificación, lo cual los hace idóneos
como la mejor plataforma de desarrollo móvil.

20
Figura 18. Justificación del desarrollo del prototipo en dispositivos PDA.
Una vez que se ha determinado que los dispositivos PDA son los mejores en aplicaciones de
cómputo móvil, se justifica el desarrollo en plataforma PPC por ser la plataforma que más ha
crecido en los últimos años. Esta tendencia seguirá por muchos años más, tal y como se
muestra en la Tabla 1.
Compañía Ventas
2T05
Participación
de mercado
2T05 (%)
Ventas
2T04
Participación
de mercado
2T04 (%)
Crecimiento
2T05- 2T04
(%)
Windows
CE
1, 653,
638
45.7 1, 006, 923 36.6 64.2
Research
In Motion
840,000 23.2 510,000 18.6 64.7
Palm OS 678,570 18.8 1,147,667 41.8 -40.9
Symbian 275,000 7.6 - 0.0 N/A
Linux 28,000 0.8 27,500 1.0 1.8
Otros 140,000 3.9 56,710 2.1 147.6
Total 3, 615,
608
100.0 2, 748, 800 100.0 31.5
Tabla 1. Comparativa de ventas de equipos PDA por sistema operativo.

21
8.3 Acaparamiento
En la Tabla 2, se resume los conceptos de acaparamiento, replicación, caching y precarga que en
ocasiones se les suele confundir con mucha frecuencia.
A B C D E F G H I
Replicación Si/
No
Si/
No
Si Si/
No
Si Heurística
/Costos
Si/
No
Híbrido Si
Acaparamiento Si No No Si No Minería de
datos
(Heurística)
No Implícito Si/
No
Precarga Si/
No
Si No Si Si Posiciones
consecutivas
No Implícito No
Caching Si/
No
Si Si/
No
No Si LRU Si Explícito Si/
No
Tabla 2. Comparativa entre los conceptos de replicación, acaparamiento, precarga y caching.
En donde:
A = Desconexión
B = En línea
C = Tolerante a fallas
D = Predicción
E = Optimización acceso
F = Esquema de predicción
G = Reducir latencia
H = Selección de datos
I = Reintegración
8.4 Estado del Arte
Otra de las actividades extras (no incluidas directamente en la propuesta) consistió en determinar los
trabajos relacionados, los principales se muestran a continuación de manera resumida (ver Tabla 3):
1. “Gestor de Acaparamiento de Patrones de Sitios Web en Clientes Móviles”, Gustavo
Verduzco Reyes, cenidet, agosto de 2003.
2. “Generador de patrones de navegación de usuarios aplicando Web log mining”, Gabriel
Hernández Méndez, Tesis de maestría en desarrollo, cenidet, octubre de 2005.
3. “Transformador de Contenidos Web para Asistentes Personales Digitales”, Claudia Selene
Uriarte Cabada, Tesis de maestría, cenidet, julio de 2004.
4. “Hoarding Content in M-Learning Context”, Anna Trifonova, Tesis doctoral en desarrollo,
Universidad de Trento, Italia, 2004.
5. Avantgo. http://www.avantgo.com/
6. Palm Web Clipping. http://www.palmos.com/dev/tech/webclipping/
Acaparamiento Transcodificación Pocket PC

22
[1] Si. Clientes móviles
tradicionales
No. No.
[2] No. Generador de
patrones
No. No.
[3] No. Se utiliza una caché Si. Si. Indirectamente
[4] Si. Seguimiento de las
actividades del usuario
Si. Personalización del
contenido.
Si.
[5] No. Caché. Replicación
de niveles.
No. Páginas propias
llamadas canales
Si. Indirectamente
[6] No. Caché. Replicación
selectiva en niveles.
No. Micrositios
personalizados a través
de recortes
Si. Indirectamente
Prototipo Si. Optimizado para
dispositivos móviles
PPC. Aportación.
Si. HTML a subconjunto
de HTML. Posiblemente
a XHTML-MP.
Si. Servicio.
Aportación.
Tabla 3. Estado del arte propuesto.
También dentro del estado del arte se abordaron literatura especializada que no está del todo
relacionada pero es de interés para el desarrollo de nuestro prototipo.
Otras herramientas existentes que realizan la replicación de sitios Web con el objetivo de
trabajar en desconexión son: Webcopier, Webstripper y WinHTTrack para PC; RepliGo,
WebCoppier, World Off-line y Pocket WebClipping para PPC. Skweezer es un transformador
de contenidos de Web para plataformas móviles como PDAs y celulares de última generación.
8.5 Más actividades
Como actividades realizadas de manera adicional se complementó el marco teórico y el
estado del arte, entre las cuales destacan:
> Dispositivos móviles
> Clasificación de los dispositivos móviles.
> Tipos de aplicaciones para dispositivos móviles.
> Puntos a tomar en cuenta cuando se desarrollan aplicaciones para dispositivos móviles.
> Diferencias entre sistema operativo y plataforma.
> Definición y características de las plataformas Pocket PC 2000, 2002 y 2003.
> Arquitectura Pocket PC.
> Redes inalámbricas disponibles en equipos PPC.
> Diferencias entre código gestionado y nativo.
> Compiladores cruzados.
> Linux en sistemas empotrados (de esta actividad se publicó un artículo técnico en un
congreso internacional [ver sección Publicaciones]).
> Tipos de aplicaciones en dispositivos móviles (Stand alone, Online y Smart Client).
> Sockets asíncronos en C#.
> Arquitectura de .NET.
> Modelo cliente – servidor (síncrono interactivo, interacción asíncrona)

23
> Se investigó sobre el tema de agentes para saber si nuestro desarrollo cumplía con las
características de un agente.
> Se investigó la tecnología AJAX que se piensa será un nuevo cambio de paradigmas en
la programación de aplicaciones en la Web.
8.6 Publicaciones
Durante el desarrollo de este trabajo de tesis se publicaron los siguientes artículos técnicos:
• González S., J. G., Montes R., A., Olivares R., J. C, “Comparativa y evaluación de las
herramientas de programación para desarrollar aplicaciones en dispositivos Pocket PC” 6to.
Congreso Internacional de las Ciencias Computacionales CICC’05, Colima, Colima, México,
del 28 al 30 de septiembre de 2005.
• González S., J. G., Montes R., A., Sosa S., V. J., Olivares R., J. C., “Gestor de acaparamiento
de sitios Web transcodificados para plataforma Pocket PC”. 3er. Congreso de Innovación e
Investigación y Desarrollo Tecnológico CIINDET’05, Cuernavaca, Morelos, México, del 27 al
30 de septiembre de 2005.
• González S., J. G., Montes R., A., Sosa S., V. J., Olivares R., J. C, “Evaluación de Windows CE
y Linux Embedded sobre Plataformas iPaq Pocket PC Modelos 3600”. Aceptado en el 6to.
Simposium Iberoamericano de Computación e Informática SICI’05, Monterrey, Nuevo Léon,
México, del 15 al 17 de Noviembre de 2005.
9 Actividades a realizar para el siguiente período
ENE FEB MAR ABR
# Concepto 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
5 Diseño e implementación del GAP
Gestor de Acaparamiento Local
Pruebas
6 Adaptación del GAP
ARM
MIPS
SH3
7 Diseño e implementación del GAS X X
Analizador HTTP
Integración del transcodificador X X
Integración del acaparador
Segunda presentación cuatrimestral
Redacción de un artículo de divulgación
Sincronizador de caches
Tabla 4. Cronograma de actividades enero-abril de 2006.
30%

24
Para el próximo cuatrimestre se terminará las actividades pendientes de este período, a su vez, se espera
básicamente terminar el desarrollo del prototipo del GAP en dispositivos PPC así como tener al menos
el 50% del GAT. Se desea adquirir el 70% de avance del proyecto de tesis.
10 Referencias
[Val02] 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.
[Hen05] Hernández Méndez, Gabriel. “Generador de patrones de navegación de usuarios aplicando
Web log mining”, tesis de maestría en desarrollo, cenidet, noviembre de 2005.
[Uri04] Uriarte Cabada, Claudia Selene. “Transformador de Contenidos Web para Asistentes
Personales Digitales”, tesis de maestría, cenidet, julio de 2004.
[Ver03] Verduzco Reyes, Gustavo, “Gestor de Acaparamiento de Patrones de Sitios Web en Clientes
Móviles”, tesis de maestría, cenidet, agosto de 2003.
[Ala02] 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.
[Jua05] Juárez Pérez Fredy, “Servidor Proxy Caché con Soporte a Operaciones en Modo Desconexión
en Redes Inalámbricas”, tesis de maestría, cenidet, febrero de 2005.

Reporte1

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (20)

Similaire à Reporte1

Similaire à Reporte1 (20)

Plus de Juan Carlos Olivares Rojas

Plus de Juan Carlos Olivares Rojas (20)

Reporte1