Arquitectura de una caché para almacenar sitios Web en dispositivos móviles Pocket PC

Transcripción

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

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

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

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

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

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

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

8 Centro Nacional de Investigación y Desarrollo Tecnológico (cenidet), de septiembre de 2001 a agosto de 2003, financiamiento COSNET: P. CURRÍCULUM Juan Gabriel González Serna es Ingeniero en Sistemas Computacionales por el Instituto Tecnológico de Acapulco (ITA) en 1992 y Maestro en Ciencias en Ciencias de la Computación por el cenidet en Profesor Investigador del Departamento de Ciencias Computacionales del cenidet en el área de Sistemas Distribuidos desde 1995 a la fecha. Candidato a Doctor en Ciencias de la Computación por el CIC del IPN. Sus áreas de interés son: Redes inalámbricas (802.11x y Bluetooth), Minería de uso de la Web y Sistemas Distribuidos. Azucena Montes Rendón es Licenciada en Matemáticas por parte de la Universidad Autónoma Metropolitana en Realizo Maestría en Matemáticas e informática aplicada así como Doctorado en Matemáticas en la Université de Paris-Sorbonne en Francia, en 1998 y Sus áreas de interés son: Tratamiento informático del lenguaje natural, Web semántica e inteligencia artificial. Víctor Jesús Sosa Sosa es Doctor en Ciencias de la Computación por la Universidad Politécnica de Cataluña (UPC-Barcelona, España) en convenio con el Centro de Investigación en Computación del IPN. Es Vicepresidente de la Asociación Nacional de Investigación en Ciencias Computacionales (ANICC) desde Octubre 2002 a la fecha. Sus áreas de interés son: Sistemas distribuidos, Programación en el Web, Bases de datos y Sistemas operativos. Juan Carlos Olivares Rojas Es Ingeniero en Sistemas Computacionales por el Instituto Tecnológico de Morelia. Actualmente realiza postgrado de Maestría en Ciencias en Ciencias de la Computación en la especialidad de Sistemas Distribuidos en el Centro Nacional de Investigación y Desarrollo Tecnológico (CENIDET). También es vicepresidente de la rama estudiantil del CENIDET-IEEE. Sus áreas de interés son el cómputo móvil, redes de telecomunicaciones y base de datos.