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

AnalizadorHTTP

GAT

WInternet

Squid

¿

¿Transcodificada??

Transcodificador

¿Actual?

Acaparador

T

Caché

Sincronizadorcaché servidor

Sincronizador

caché local

Sí

Sí

No

No

Patrón

GDL

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áginatranscodificada

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

AnalizadorHTTP

GAT

WInternet

Squid

¿

¿Transcodificada??

Transcodificador

¿Actual?

Acaparador

T

Caché


Sincronizador

caché local

Sí

Sí

No

No

Patrón

GDL

GAL

MT

MA

Observador




GAP

Cliente Pocket PC


¿Conexión?

¿Caché?

T caché

Sí

No

No

Error

Sí

recurso

AnalizadorHTTP

GAT

WInternet

Squid

¿

¿Transcodificada??

Transcodificador

¿Actual?

Acaparador

T

Caché


Sincronizador

caché local

Sí

Sí

No

No

Patrón

GDL

GAL

MT

MA

Observador



Petición Respuesta

Recurso

Revisar

estado de la

conexión

Fecha


Arquitectura GASWT

Descomprime

Comprime



GAP

Cliente Pocket PC


¿Conexión?

¿Caché?

T caché

Sí

No

No

Error

Sí

recurso

AnalizadorHTTP

GAT

WInternet

Squid

¿

¿Transcodificada??

Transcodificador

¿Actual?

Acaparador

T

Caché


Sincronizador

caché local

Sí

Sí

No

No

Patrón

GDL

GAL

MT

MA

Observador




GAP

Cliente Pocket PC


¿Conexión?

¿Caché?

T caché

Sí

No

No

Error

Sí

recurso

AnalizadorHTTP

GAT

WInternet

Squid

¿

¿Transcodificada??

Transcodificador

¿Actual?

Acaparador

T

Caché


Sincronizador

caché local

Sí

Sí

No

No

Patrón

GDL

GAL

MT

MA

Observador



Petición Respuesta

Recurso

Revisar

estado de la

conexión

Fecha


Arquitectura GASWT

Descomprime

Comprime



GAP

Cliente Pocket PC


¿Conexión?

¿Caché?

T caché

Sí

No

No

Error

Sí

recurso

AnalizadorHTTP

GAT

WInternet

Squid

¿

¿Transcodificada??

Transcodificador

¿Actual?

Acaparador

T

Caché


Sincronizador

caché local

Sí

Sí

No

No

Patrón

GDL

GAL

MT

MA

Observador




GAP

Cliente Pocket PC


¿Conexión?

¿Caché?

T caché

Sí

No

No

Error

Sí

recurso

AnalizadorHTTP

GAT

WInternet

Squid

¿

¿Transcodificada??

Transcodificador

¿Actual?

Acaparador

T

Caché


Sincronizador

caché local

Sí

Sí

No

No

Patrón

GDL

GAL

MT

MA

Observador



Petición Respuesta

Recurso

Revisar

estado de la

conexión

Fecha


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

Documents

Transcript of Reporte1