Gestor de Acaparamiento de Sitios Web Transcodificados para Plataforma Pocket PC

Gestor de Acaparamiento de Sitios Web Transcodificados para Plataforma Pocket PC Juan Carlos Olivares R. 1, J. Gabriel González Serna1, 2, Azucena Montes Rendón1 1

Centro Nacional de Investigación y Desarrollo Tecnológico Cuernavaca, Morelos, 62490 México 1, 2

Centro de Investigación en Computación (CIC-IPN) México, D.F.

Resumen: Dado el gran auge que ha tenido los dispositivos móviles, en este artículo se presenta una propuesta de solución para el problema de las frecuentes desconexiones en clientes móviles del tipo Pocket PC, en lo referente a la visualización de páginas Web. También se muestra el estado de arte y marco teórico de esta tecnología. Abstract: This paper shows a methodology to resolve the problem of the frequent disconnections in mobile clients like Pocket PC, in the context of Web pages visualization. Keywords: Pocket PC, Hoarding, Transcoding, Mobile clients, Wireless networks, PDA.

otros equipos. La conectividad se mediante el uso de redes inalámbricas.

logra

Los dispositivos móviles presentan el problema de frecuentes desconexiones, la cual se presenta de manera más atenuada en este tipo de arquitectura que en una plataforma de cómputo convencional. Este problema genera, entre otras cosas, que se pierda información o que no se pueda realizar algún proceso como es debido [1]. Además, este tipo de nuevas tecnologías presentan dificultades en la forma en como se presenta la información a los usuarios, debido principalmente a las limitaciones de las pantallas de despliegue y al limitado poder de procesamiento (comparado con equipos convencionales.

1. Introducción En la actualidad, gracias a los grandes descubrimientos en ciencia y tecnología, es posible que las personas puedan entre otras cosas, comunicarse y compartir información entre sí en cualquier momento, a toda hora y en todo lugar. A esto se le ha denominado cómputo penetrante (pervasive computing). Uno de los avances tecnológicos que ha hecho posible todo esto es, sin duda, los dispositivos móviles. Los dispositivos móviles son hoy en día muy diversos, entre los que destacan los teléfonos inteligentes (smart phones), los asistentes personales digitales (PDA ), las computadoras portátiles, las computadoras de mano (handheld) o de bolsillo (Pocket PC), así como los sistemas integrados (embedded systems) tales como terminales de punto de venta, cajeros automáticos, etc. Dichos equipos se han vuelto muy populares debido principalmente a que su costo disminuye día con día, mientras que su poder de procesamiento aumenta vertiginosamente. Entre las características principales de estos dispositivos se encuentran dos: su reducido tamaño y su conectividad con

La tendencia más generalizada en nuestros días es que los equipos móviles converjan junto a las plataformas convencionales en una sola; es decir, en un futuro no muy lejano, se espera que no exista mucha diferencia entre estas arquitecturas. Internet está jugando un papel muy importante en este menester, actuando como catalizador para lograr la convergencia.

2 Marco conceptual Para el buen entendimiento de este artículo, es necesario explicar algunos conceptos que aclaren básicamente las siguientes preguntas: ¿Qué es acaparamiento? ¿En qué consiste la transcodificación de contenidos Web? ¿Qué es un dispositivo Pocket PC? 2.1 Acaparamiento El acaparamiento (hoarding) se puede definir como el proceso de replicación y procesamiento en desconexión de datos previamente seleccionados y copiados localmente en el cliente móvil [2].

El acaparamiento surge del hecho de que las desconexiones, tanto planeadas como accidentales, no están consideradas en las arquitecturas tradicionales, en particular con la arquitectura cliente/servidor. En informática, el concepto de acaparamiento es un proceso integral, el cual incluye las etapas de acaparamiento de datos, desconexión y reintegración. 2.1.1 Estado de acaparamiento de datos Los recursos requeridos para las operaciones son precargados en la unidad móvil. La reubicación de los datos es simple, debido a que los datos son inaccesibles para otros sitios y para otros nodos. Para predecir las desconexiones de los equipos móviles, se deben acaparar los recursos periódicamente para poder trabajar en modo desconexión. La pregunta medular en esta fase consiste en ¿cómo anticipar las necesidades futuras de los usuarios móviles? Una alternativa consiste en que los usuarios especifican explícitamente los datos que quieren; otra alternativa es de manera implícita, la cual consiste en examinar el historial de acceso a los datos por parte del usuario, para tratar de predecir de manera más óptima los recursos a acaparar. 2.1.2 Estado de desconexión

definidos por el usuario, o los recursos más accedidos. 4. ¿Cómo acaparar? Esta pregunta es sumamente difícil de contestar, debido a que existen diversas metodologías de solución, las cuales resuelven problemas específicos. 2.1.4 Acaparamiento de sitios Web Una de las características más preponderantes que tienen las páginas Web, es que son más usadas para la visualización que para las actualizaciones, por lo que este hecho conlleva un nuevo replanteamiento de la metodología de acaparamiento, en este caso se debe determinar ¿qué páginas se deben acaparar? Para soportar operaciones en modo desconexión, la política de acaparamiento debe ser extendida para cargar todos los documentos de páginas previamente visitadas por el usuario o anticipar las páginas que pueden ser visitadas por el usuario. Otro de los retos a resolver con respecto al acaparamiento de páginas Web consiste en la persistencia de la caché, la cual es crítica durante las frecuentes desconexiones de los equipos móviles. El acaparamiento no se puede dar con la falta o ausencia de la caché. En resumen, el esquema de acaparamiento consta de los siguientes pasos:

En este estado, las aplicaciones usan solamente los datos disponibles de manera local. La petición de los recursos se puede realizar insertado dichas peticiones en una cola para ser atendida a la brevedad, cuando ocurra un evento de reconexión.

1. Identificación de patrones de acceso. 2. Selección de los recursos que serán replicados. 3. Control de reintegración de réplicas.

2.1.3 Estado de reintegración

Por transcodificación (transcoding) se entiende el proceso de convertir un formato o código a otro, con la finalidad de que este nuevo formato o código se adapte a la plataforma indicada para su correcta visualización [3].

En esta etapa se debe responder a las siguientes interrogantes: 1. ¿Cuál debe ser la unidad de acaparamiento: bloques de archivos, archivos, grupos de archivos o directorios? 2. ¿Cuándo se debe acaparar? La respuesta es: cuando se necesita la información (i.e., cuando la información es crítica). 3. ¿Qué recursos se deben acaparar? En esta pregunta existe una gran diversidad de respuestas; por ejemplo, se deben acaparar los recursos de mayor prioridad, los recursos

2.2 Transcodificador de contenidos Web

El mecanismo de transformación o transcodificación de contenidos Web, lleva a cabo una reorganización y agrupación de los elementos contenidos en la página Web solicitada, y de acuerdo a la delimitación del lenguaje de entrada (HTML ), dicho mecanismo se aplica sólo a un subconjunto del universo de documentos que se encuentran en Internet[4]. Como resultado final de la transcodificación, se obtienen páginas Web cuyo formato de presentación o visualización es óptimo para un

dispositivo de despliegue limitado, tratando de respetar fielmente la semántica original del documento o página.

fuerte reconocimiento de voz para la mayoría de las acciones del sistema. 2.3.2 Características

2.3 Pocket PC El objetivo de este apartado es dar una idea general sobre el tema, por lo que no profundizamos en términos técnicos referentes a la electrónica de estos dispositivos. 2.3.1 Historia El primer antecedente de lo que ahora conocemos como Pocket PC (PPC), fue el Newton de la compañía Apple desarrollado en 1993; sin embargo, fue un fracaso total, debido en parte a sus altos costos y a que la tecnología para estos dispositivos aún se encontraba en pañales. En 1996 surge la Palm Pilot, la cual se convertiría en un éxito total, llamando la atención del mercado y convirtiéndose en el primer PDA en ser popular. Por las mismas fechas, y como respuesta de Microsoft por tener una parte del negocio de los dispositivos móviles, aparece Windows CE. Dicho sistema operativo portó la mayoría de las bibliotecas de Windows de 32 bits para hacerlo lo más compatible posible permitiendo a los usuarios realizar las mismas acciones que en su PC de escritorio. Es hasta el año 2000 cuando aparece la versión 3.0 de Windows CE y con ella la plataforma Pocket PC. Si bien Windows CE 3.0 es el sistema operativo, la palabra Pocket PC (PPC) designa dispositivos con ciertas características impuestas por Microsoft a los fabricantes para sus dispositivos. En el 2002 surge la plataforma Pocket PC 2002 (PPC 2002), que aunque bien se basa en Windows CE 3.0 toma algunas ideas de Windows CE .NET. En el 2003, Microsoft evoluciona su concepto de cómputo móvil y presenta la plataforma Windows Mobile, que tiende a agrupar tanto a dispositivos PPC 2003 como teléfonos inteligentes. La versión más actual de esta arquitectura recibe el nombre de Windows Mobile 2003 Second Edition, la cual tiene como sistema operativo Windows CE 4.2. Se acaba de anunciar la nueva versión de la plataforma Pocket PC cuyo nombre será Windows Mobile 5, el cual se lanzará a finales de este año. Su característica principal será el

Entre las principales características de estos dispositivos se encuentran: • Funcionalidad PIM (Personal Information Manager), lo que en español conocemos como Organizador electrónico, el cual, lejos de ser una simple agenda electrónica, incluye herramientas de gestión de información personal tales como la posibilidad de enviar correos electrónicos, programar tareas y notas. • Poseen algún tipo de conectividad, es decir, cuentan con algún tipo de Interfaz de red, actualmente la gran mayoría posee interfaces de red inalámbrica del tipo WiFi (IEEE 802.11) y/o Bluetooth (IEEE 802.15). • Tienen despliegue de pantallas muy limitados. Por ejemplo, la resolución debe ser de 240x320 píxeles, deben contar con pantallas a color con por lo menos 16 colores, capacidad de iluminación de la pantalla, pantalla táctil (sensible al tacto). • Deben contar con un dispositivo señalador de tipo pluma, conector de audífonos, micrófono integrado, bocinas, puerto externo (serial o USB) de sincronización, ranura para tarjetas de expansión (PCMCIA, Compact Flash, SD, etc.), además de baterías recargables. • Baja capacidad de procesamiento de datos, en comparación con arquitecturas tradicionales, pero dichos procesadores se encuentran optimizados para las tareas que realizan. • Cuentan con memoria limitada tanto de almacenamiento primario como secundario, generalmente las memorias son del tipo FlashROM las cuales permiten grabar y borrar datos de manera permanente. Aquí tanto la RAM como la ROM sirven para almacenar datos como programas, esto debido a que, mientras tenga energía la batería, alimentará la memoria RAM evitando la pérdida de información. 2.3.3 Procesadores Las PPC presentan una arquitectura abierta, por lo que se ha utilizado hardware muy diverso en su construcción; en particular a lo referente a sus microprocesadores, de los cuales se tienen varios y que es necesario describirlos brevemente [5] y [6].

2.3.3.1 Familia ARM El primer microprocesador para PPC y el más popular, fue el ARM (Advanced RISC Machines), el cual fue diseñado y manufacturado por Acorn Computer Group a mediados de los 80s. El ARM es un microprocesador CMOS de 32 bits diseñado en arquitectura RISC , lo cual significa que tiene un reducido conjunto de instrucciones en comparación con arquitecturas CISC como x86 (familia de microprocesadores de Intel) o m68k (familia de microprocesadores de Motorola). StrongARM, resultado del trabajo de ARM Ltd. y Digital, usa el conjunto de instrucciones de los procesadores ARM, pero el cual es construido con los chips de bajo costo de las series Alpha. Digital vendió su manufacturación de chips a Intel Corporation. La famosa iPaq (la PPC más vendida) de Compaq (ahora HP) utiliza este microprocesador. La iPaq es la PPC donde más esfuerzo se ha realizado para tratar de portar Linux al mundo de las PPC; de hecho, actualmente existen versiones muy estables de Linux como los proyectos Pocket Linux, iPaq Linux, Opie, Familiar, entre otros. Xscale es un microcroprocesador del tipo RISC SIMD (Single Instruction Multiple Data). Este chip es fabricado por Intel, por lo que actualmente su uso está creciendo enormemente. Con la aparición de Windows Mobile 2003, Microsoft ha determinado que dejará de ofrecer su sistema operativo Windows CE para PPC para microprocesadores que no sean descendientes de la familia ARM. Esto debido principalmente a dos razones: la primera, referente a la dificultad de mantener códigos diferentes de distintos microprocesadores y segunda, porque ARM está dominando y según Microsoft dominará el mercado de PPC por muchas años más, gracias a la participación activa de Intel. 2.3.3.2 Familia MIPS MIPS es un microprocesador del tipo VLSI RISC de 32 bits desarrollado por la compañía japonesa NEC, que cuenta entre sus características principales que permite entubamiento y cuenta con un software reorganizador de códigos, que entre otras cosas, permite un mayor rendimiento. Cada instrucción en promedio es realizada en dos ciclos de reloj.

Este tipo de microprocesadores son muy usados en ambientes de servidores, estaciones de trabajo y mainframes. Desde su diseño se trató de portar toda la funcionalidad y robustez con que cuentan estos microprocesadores al ambiente móvil. La PPC más venida en Japón, la Cassiopedia de la compañía Casio utiliza este microprocesador. 2.3.3.3 Familia SH SH3 es desarrollado por la compañía japonesa Hitachi, pertenece a la familia de microprocesadores Super H (Hitachi), los cuales son microprocesadores de 32 bits con instrucciones de 16 bits. Entre las características principales de un microprocesador SH3 podemos destacar las siguientes: su diminuto tamaño y su bajo consumo de energía, lo cual lo hacen ideal para sistemas de cómputo móviles o sistemas multimedia. La ahora extinta, PPC Jornada de la compañía HP utilizaba este tipo de microprocesador. Actualmente, están disponibles en el mercado las mejoras de este procesador llamadas SH4 y SH5.

3. Descripción del problema La Web es uno de los servicios más utilizados de la Internet, motivo por el cual su funcionamiento es crítico en muchos entornos de nuestra sociedad. Los equipos móviles están propensos a constantes desconexiones y, por otra parte, la Web por naturaleza, requiere de una conexión permanente para poder operar. Por este motivo, es necesario un mecanismo para poder hacer accesible los recursos de un sitio Web sin necesidad de conexión. Por otra parte, debido a las limitantes de los dispositivos móviles, los sitios Web no pueden ser visualizados correctamente en esta clase de dispositivos, razón por la cual se requiere de un mecanismo para poder visualizar correctamente las páginas Web en un dispositivo móvil con despliegue limitado. El nivel de complejidad que se identifica en el desarrollo de aplicaciones para plataforma PPC es sumamente alto, el problema fundamental es el siguiente: Se pueden encontrar dispositivos PPC con diferentes microprocesadores (e.g.

ARM, SH3, MIPS, etc.); para cada microprocesador se debe desarrollar una aplicación, lo que conlleva a la transportabilidad del código fuente para crear código ejecutable para cada plataforma, lo cual implica la existencia de un compilador para cada microprocesador. En este apartado, se debe tener en cuenta que la diversidad de microprocesadores puede llevar a cambios en la forma de implementar algunas funciones o instrucciones; sin embargo, la lógica del programa no cambia por que la implementación de nuestro agente intermediario se hará en lenguajes de alto nivel, en contraste con un lenguaje de bajo nivel (ensamblador), donde cada programa es dependiente de la arquitectura (un programa para un tipo de microprocesador es único para ese tipo de microprocesador). Otro de los problemas de mayor complejidad que presenta este proyecto, consiste en el manejo del acaparamiento de sitios Web transcodificados en un dispositivo PPC, debido principalmente a los siguientes subproblemas: 1. Los mecanismos de replicación o precarga están muy orientados a base de datos y memoria caché, y prácticamente no existen mecanismos que permitan el acaparamiento de recursos informáticos, en especial con sitios Web y en particular con los dispositivos móviles PPC. 2. La mayor problemática que presenta el acaparamiento consiste en el control de las réplicas tanto de manera local como del lado del servidor, es por ello que se necesita un módulo o mecanismo controlador que gestione la negociación de dichas réplicas de tal forma que sea automatizado y transparente para el usuario. 3. Otros de los factores a considerar en cuanto a la cuestión del acaparamiento es el tamaño de los recursos, debido a las limitantes de almacenamiento impuestas a los dispositivos PPC, esto hace necesario que exista un mecanismo que controle el tamaño máximo de los recursos a acaparar, el tipo de archivos a acaparar, el tamaño máximo destinado al acaparamiento en general, el directorio local de almacenamiento, por mencionar algunas restricciones Tanto el manejo de eventos de conexión cómo de reconexión, no están pensados en una arquitectura cliente servidor tradicional, ya que el modelo cliente/servidor en clientes móviles esta inmerso en un ambiente de continuas desconexiones, se hace necesario de un mecanismo que controle y administre los eventos de desconexión. Esto con lleva a un

cambio de paradigmas en la forma de realizar software de red, se debe tener presente que las desconexiones ocurren de forma más frecuente que en otro tipo de plataformas. 3.1 Objetivo del proyecto El objetivo general de este proyecto consiste en diseñar e implementar un prototipo de agente intermediario para plataforma Pocket PC 2000, que gestione el acaparamiento de páginas Web transcodificadas cuando se presenten eventos de desconexión.

4. Antecedentes del proyecto Este proyecto de tesis forma parte de la arquitectura del proyecto “Moviware” [7]. La finalidad de Moviware consiste en dar soporte a clientes móviles inalámbricos que operan en un ambiente de red inestable, sujetos a experimentar diversos fenómenos mientras se encuentran trabajando. Es una plataforma prototipo que se compone de los siguientes módulos: 1. Gestor (“broker”) de desconexión y reconexión. Este componente se encarga de gestionar y procesar los eventos de desconexión que se puedan presentar de manera voluntaria (si el cliente lo solicita explícitamente) o involuntaria (sin previo aviso). 2. Generador de patrones de acceso a sitios Web basado en algoritmos de minería de reglas de asociación. Estos componentes extraen patrones de acceso en base a mecanismos de minería de datos. Los patrones generados son clasificados y colocados en un contenedor para su posterior recuperación en base a criterios de selección que el gestor de acaparamiento determina. 3. Gestor de acaparamiento de recursos informáticos. Tiene la función de interpretar el perfil de conducta de los usuarios móviles para poder identificar el patrón de acceso que permita la precarga de los recursos informáticos que el patrón indique. También proporciona los servicios para el procesamiento de los recursos acaparados en modo de desconexión. 4. Gestor de contenidos Web. Este componente se encarga de devolver recursos Web a dispositivos móviles, atendiendo a las características particulares de esos dispositivos. La arquitectura de MoviWare es la siguiente:

HTTP HTTP

Cliente Móvil Inalámbrico

FTP FTP

Aplicación (Netscape, Explorer, Pocket IE

Gestor de Gestor de Desconexión Desconexión

Proxy Cache Squid Cache

Gestor de caches

Intermediario

Identificador De perfil de dispositivo

Gestor de Cache de Acaparamiento

Gestor Local de Acaparamiento

IEEE 802.11

Recurso Acaparado

Encapsulador de patrón Generador de árbol Patrón

Identificador de Patrón Gestor de Acaparamiento

Historial De Accesos

Minero Clasificador de Patrones

Patrones Generador de Patrones

Analizador de Página HTML Generador de página Web Transcodificada

Cache transcodificada Transcodificador de contenidos Web

Intranet

Figura 1. Arquitectura Moviware. En el óvalo con línea continua, se muestra la parte fundamental en donde se centrará este proyecto. En el óvalo con línea punteada en círculos, se muestra el origen de donde nuestro proyecto sacará el acaparamiento de los datos. Para finalizar, en óvalos con líneas punteadas en cuadrados, se muestran los módulos con los que interacciona nuestro proyecto y que es necesario integrar y/o adaptar para su correcto funcionamiento en esta plataforma.

En [2] se muestra la base para realizar el acaparamiento; es decir, mediante algoritmos de minería de uso Web aplicados a bitácoras de servidores Web, encuentra un conjunto de Reglas de asociación que permiten predecir los posibles recursos que el usuario podría necesitar; dichas reglas se guardan en un contenedor de patrones, y es de aquí de donde nuestro proyecto va partir para realizar el acaparamiento.

5. Trabajos relacionados

Esta aplicación no realiza acaparamiento, es decir, por si sola no tiene una aplicación final visible a los usuarios. Actualmente se está realizando un trabajo de tesis dentro del cenidet que pretende mejorar la funcionalidad de este trabajo.

Aunque existen muchos trabajos relacionados con el acaparamiento, éstos se enfocan a base de datos (replicación) y memoria (precarga), por lo que el abanico de trabajos relaciones disminuye considerable. En [8] se plantea una metodología (la cual servirá de base para replantear nuestra propia metodología) para realizar acaparamiento en dispositivos móviles, desgraciadamente estos dispositivos móviles comprenden plataformas convencionales (laptops y computadoras de escritorios) con interfaces de red inalámbricas. Otra deficiencia que presente este trabajo, consiste en que no realiza transcodificación de contenidos Web.

En [4] se propone una metodología (la cual se tiene contemplada integrar en este trabajo de tesis) para realizar la transcodificación de páginas Web, desgraciadamente no realiza acaparamiento de estas páginas ya transcodificadas y aunque está enfocada para dispositivos PPC, no se realiza ningún procesamiento (programación) en éste. El trabajo de transcodificación se realiza en un intermediario que se encuentra del lado del servidor, el cual pertenece a un equipo de cómputo tradicional.

En [9] se presenta un middleware para dispositivos móviles que gestiona diversos recursos cuando se presentan eventos de desconexión, en este sentido este trabajo tiene una gran similitud con nuestro tema de tesis, la primera diferencia fundamental consiste en el área que se cubre. En nuestro tema de tesis el enfoque es de manera general para cualquier sitio (con sus respectivas limitantes), mientras que en este trabajo relacionado, se enfoca hacia una aplicación de aprendizaje móvil (MLearning) denominada m-Eldit (versión móvil del programa de e-Learning ‘Eldit’ ). Otro aspecto muy similar de este proyecto con el nuestro, consiste en que este trabajo relacionado realiza acaparamiento basado en el seguimiento (tracking) del usuario, es decir, la predicción de los recursos a acaparar se realiza de manera más sencilla, debido a que deduce los posibles recursos a acaparar en base a los recursos faltantes que tiene que completar dicho usuario; es decir, el acaparamiento se realiza de manera especial para cada usuario, mientras que en nuestro tema de tesis el acaparamiento se realiza de manera general para todos los usuarios. Para dejar más claro esto, supongamos que el usuario X ha tomado los temas uno, dos y cinco de un curso de 6 lecciones, por lo que lo más probable es que a futuro, el usuario ocupe los cursos tres, cuatro y seis.

Mientras que en un sitio Web, determinar que recursos se deben acaparar a los usuarios es más complejos, ya que las preferencias de los usuarios son extremadamente variantes. Este trabajo de tesis utiliza y propone una metodología de acaparamiento que está enfocada hacia dispositivos PPC; también realiza un tipo especial de transcodificación, dicha transformación se realiza de forma personalizada gracias a que se cuenta con el perfil del usuario. La personalización realizada en este trabajo, consiste simplemente en el cambio de parámetros a visualizar, como son los colores de la interfaz, el tamaño de las letras etc.; mientras que en nuestro trabajo la transcodificación se realiza de manera genérica de todos los sitios Web.

6. Metodología de la solución El esquema de solución que se propone consiste en una adaptación del esquema cliente/servidor orientada a clientes móviles, este modelo consta tanto de clientes móviles, como de un servidor encargado de brindar servicios de recursos Web; en medio de nuestros clientes y servicios se encuentra nuestra capa de intermediarios, tanto del lado del cliente como del lado del servidor, el modelo general propuesto puede visualizarse en la figura 2.

Internet

ARM

SQUID

MIPS

SH3

GAS GAP

Servidores Web

GAS=Gestor de Acaparamiento del Servidor GAP=Gestor de Acaparamiento Pocket

Figura 2. Esquema general de la arquitectura propuesta. La arquitectura propuesta (ver figura tres) consta de manera general de dos partes, la primera parte del lado del dispositivo cliente móvil PPC, del otro lado, se muestra el

mecanismo del lado del servidor. Entre estas dos partes, se encuentra la interfaz de red inalámbrica (en nuestro caso IEEE 802.11).

Del lado cliente, se encuentran dos partes claramente diferenciadas, la primera es la aplicación final al usuario, en nuestro caso, el navegador (e.g. Pocket Internet Explorer u otros.) que solicita recursos Web.

Por el otro, se encuentra el intermediario que se va a desarrollar, en nuestro caso lo hemos denominado GAP (Gestor de Acaparamiento Pocket). Dicho intermediario consta de los siguientes componentes:

Cliente Pocket PC Navegador Navegador(IPE, (IPE,Netscape) Netscape)

Sí

No ¿Actual?

Squid

Observador Analizador HTTP

Transcodificador

Internet

W

G D

Sí

Sí ¿Conexión?

L

Caché transcodificada

No

No

¿Transcodificada?

WiFi Gestor de Desconexión

No
Error ¿Caché?

MT

Conversión local / Web

Acaparador

Éxito

T

Sincronizador Caché servidor

MA

GAS

Sí

T Caché transcodificada

Sincronizador Caché local

Módulos a integrar pertenecientes a Moviware

GAL

GAP Figura 3. Arquitectura propuesta. 1. Observador.- También llamado vigía, su objetivo fundamental es revisar y procesar las peticiones tanto de entrada como de salida que van o vienen dirigidas a la aplicación (navegador Web). 2. Gestor de Desconexión (GDL).- Tiene la función de revisar el medio físico de conexión y determinar si el cliente se encuentra conectado o no.

mensaje de error, el observador deberá construir una página Web con un mensaje de error que el usuario visualizará. b. Controlar la sincronización de la caché transcodificada local con la caché del Servidor.

3. Gestor de Acaparamiento Local (GAL).Cuya misión consiste fundamentalmente en dos cosas:

Del lado del servidor, encontramos dos elementos principales: el servidor Proxy caché Squid, encargado de obtener los recursos Web solicitados; y el intermediario del lado del servidor, el cual hemos denominado GAS (Gestor de Acaparamiento del Servidor), esta arquitectura consta de los siguientes elementos:

a. Revisar si existe un recurso acaparado, en caso de existir se manda el recurso solicitado (en este caso el Observador debe de cambiar el encabezado para hacer creer al navegador que la solicitud viene del exterior); en caso de no existir el recurso acaparado, se manda un

1. Mecanismo Transcodificador (MT).- Es el encargado de transcodificar (transformar una página Web para su correcta visualización en un dispositivo de despliegue limitado) los recursos Web obtenidos del servidor Squid. (Este módulo es parte de Moviware y se le harán las

modificaciones pertinentes a fin de integrarlo en este trabajo de tesis). 2. Analizador HTTP.- Es el encargado de analizar el contenido del encabezado HTTP de la solicitud del cliente, en este caso nos interesa encontrar información como el recurso solicitado, el tipo de cliente que realiza la petición (sistema operativo, tipo de microprocesador), la fecha de modificación del recurso solicitado, entre otros campos. Este analizador es similar a un módulo identificador de dispositivo. 3. Mecanismo Acaparador (MA).- Se encarga de dos funciones básicas, acaparar un sitio Web transcodificado y sincronización de la caché transcodificada, para esta última opción debe haber un control de versiones entre la caché local y la caché del servidor (este módulo existe en Moviware pero en la versión sin transcodificar, la intención es integrar este módulo y el intermediario que se desarrollará, de tal forma que detecte el dispositivo desde el cual se está realizando una petición de un recurso Web y se envié el recurso transcodificado o no). 4. Gestor de desconexión (GD).- Es el encargado de revisar el medio inalámbrico y, procesar todas las peticiones realizadas por el cliente que no pudieron ser atendidas, cuando se presentó el evento de desconexión. En lo referente a herramientas a utilizar, aun no se han definido las herramientas definitiva de desarrollo, actualmente, nos encontramos en una fase de investigación en cuanto a herramientas y entornos de programación se refiere; como posibles alternativas se tienen el uso de herramientas como el Microsoft eMbedded Tools (eMbedded Visual Basic y eMbedded Visual C++), Visual Studio .NET (Visual Basic .NET y Visual C#), así como analizar algunas variantes de Java (se deben tener máquinas virtuales especiales para PPC), como es el caso J2ME (Java 2 Micro Edition), Personal Java y Embedded Java.

2. Agilizar los tiempos de acceso a las páginas Web, al tener un sitio Web acaparado de manera local, cuando se presenten desconexiones. 3. Visualización de páginas Web de manera adecuada, de tal forma que su visualización no dependa de las limitantes de su pantalla. 4. La facilidad de administración y, por ende de programación, al no tener páginas distintas para distintas plataformas. 5. Ahorro de energía en dispositivos que dependen de un suministro finito, esto como consecuencia de trabajar en modo de desconexión. 6. Ahorro en tiempo aire, si es que el dispositivo se conecta a través de una línea de conexión celular (e.g. GSM/GPRS). Entre las limitantes que presenta este trabajo se encuentran las siguientes: 1. El GAP sólo se implementará para plataforma PPC 2000 (no se garantiza que trabaje sobre otras plataformas de PPC como PPC 2002 o Windows Mobile 2003). 2. Los microprocesadores para los cuales se generará código ejecutable del GAP son: SH3, ARM y MIPS (tampoco se garantiza que corra sobre arquitecturas de microprocesadores más modernos). 3. El acaparamiento en el GAP estará limitado a las características propias del PPC (definiremos un sistema con características mínimas para realizar el acaparamiento). 4. El GAS se limitará a los servicios proporcionados por la arquitectura Moviware (no pretendemos en principio realizar modificaciones a las funcionalidad de cada módulo a integrar, es decir, los módulos a integrar se quedarán con sus alcances y limitaciones respectivos, simplemente se realizarán modificaciones para lograr su coordinación).

7. Conclusiones 8. Referencias bibliográficas Este trabajo de investigación se encuentra en su primera etapa, por lo que hasta este momento no se cuentan con resultados relevantes. Entre los beneficios que se desean obtener de este trabajo se encuentran: 1. Visualización de páginas Web en modo de desconexión en dispositivos PPC, de manera transparente para el usuario.

[1] Alarcón Gálvez Fernando, “Mecanismo para Gestión de Conexión en Sistemas Cliente/Servidor Móviles”, tesis de maestría, cenidet, agosto de 2002. [2] Valenzuela Molina David R., “Mecanismo para Predicción de Acaparamiento de Datos en Sistemas Cliente/Servidor Móviles”, tesis de maestría, cenidet, agosto de 2002.

[3] Chanchaem Thong, “A Survey on Internet Content Transcoding for Universal Access”, Department of Computer Science, Kent State University, mayo de 2003. [4] Uriarte Cabada Claudia Selene. “Transformador de Contenidos Web para Asistentes Personales Digitales”, tesis de maestría, cenidet, julio de 2004. [5] Clark David, “Mobile processors begin to grow up”, revista IEEE Computer, pp. 2225, marzo de 2002. [6] Hattori Toshihiro, et al., “Design Methodology of a 200MHz superscalar microprocessor: SH-4” Hitachi, Ltd., Tokio, Japón. 249 IEEE Proceedings of the 35th Design Automation Conference (DAC’98) 0-89791-964-5/98. [7] González Serna Juan Gabriel. “Plataforma middleware reflexiva para aplicaciones de cómputo móvil en Internet (Movirware)”, Centro Nacional de Investigación y Desarrollo Tecnológico (CENIDET), de septiembre de 2001 a agosto de 2003, financiamiento COSNET: 570.01-P. [8] Verduzco Reyes Gustavo, “Gestor de Acaparamiento de Patrones de Sitios Web en Clientes Móviles”, tesis de maestría, cenidet, agosto de 2003. [9] Trifonova Anna, “Hoarding Content in MLearning Context”, tesis doctoral en desarrollo, Universidad de Trento, Italia, 2004. Juan Carlos Olivares Rojas Ingeniero en Sistemas Computacionales egresado del Instituto Tecnológico de Morelia en 2004. Es estudiante de la especialidad de sistemas distribuidos en la Maestría en Ciencias en Ciencias Computacionales en el Centro Nacional de Investigación y Desarrollo Tecnológico (CENIDET). Sus áreas de interés son el cómputo móvil, redes de computadoras, sistemas de telecomunicaciones y base de datos Actualmente es vicepresidente de la rama estudiantil de la IEEE del CENIDET. Juan Gabriel González Serna Ingeniero en Sistemas Computacionales por el InstitutoTecnológico de Acapulco (ITA) en 1992 y Maestro en Ciencias en Ciencias de la Computación por el cenidet en 1995. Profesor Investigador del

Departamento de Ciencias Computacionales del cenidet en el área de Sistemas Distribuidos desde 1995 a la fecha.Candidato a Doctor en Ciencias de la Computación por el CIC del IPN. Sus áreas de interés son: Redes inalámbricas (802.11x y Bluetooth), Minería de uso de la Web y Sistemas Distribuidos. Azucena Montes Rendón Licenciada en Matemáticas por parte de la Universidad Autónoma Metropolitana en 1994. Realizo Maestría en Matemáticas e informática aplicada así como Doctorado en Matemáticas en la Université de ParisSorbonne en Francia, en 1998 y 2002. Sus áreas de interés son: Tratamiento informático del lenguaje natural, formalización de la semántica y de la sintaxis.Topología y quasi-topologias. Lógica.