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

1Centro 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.

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

otros equipos. La conectividad se logra

mediante el uso de redes inalámbricas.

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.

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

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.

2.1.3 Estado de reintegración

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

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:

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.2 Transcodificador de contenidos Web

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].

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.

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

fuerte reconocimiento de voz para la mayoría de

las acciones del sistema.

2.3.2 Características

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:

Intermediario

Patrones

Gestor de Cachede Acaparamiento

RecursoAcaparado

HistorialDe

Accesos

Minero Encapsulador de

patrón

Identificador de Patrón

Cliente MóvilInalámbrico

Gestor Local de Acaparamiento

Gestor de Acaparamiento

Clasificador dePatrones

Aplicación(Netscape, Explorer,

Pocket IE

Transcodificadorde contenidos Web

Identificador De perfil de dispositivo

Generador de Patrones

Generador de árbol Patrón

Analizador dePágina HTML

Generador de páginaWeb

Transcodificada

Gestor deDesconexión

Gestor deDesconexión

HTTPHTTP

FTPFTP

Proxy Cache Squid

Cache

transcodificada

Cache

Gestor decaches

Intranet

IEEE 8

02.1

1

Intermediario

Patrones

Gestor de Cachede Acaparamiento

RecursoAcaparado

HistorialDe

Accesos

Minero Encapsulador de

patrón

Identificador de Patrón

Cliente MóvilInalámbrico

Gestor Local de Acaparamiento

Gestor de Acaparamiento

Clasificador dePatrones

Aplicación(Netscape, Explorer,

Pocket IE

Transcodificadorde contenidos Web

Identificador De perfil de dispositivo

Generador de Patrones

Generador de árbol Patrón

Analizador dePágina HTML

Generador de páginaWeb

Transcodificada

Gestor deDesconexión

Gestor deDesconexión

HTTPHTTP

FTPFTP

Gestor deDesconexión

Gestor deDesconexión

HTTPHTTP

FTPFTP

Proxy Cache Squid

Cache

transcodificada

Cache

Gestor decaches

Intranet

IEEE 8

02.1

1

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.

5. Trabajos relacionados

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 [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.

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.

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 (M-

Learning) 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.

MIPS

SH3

ARMARM

GAP

SQUID

GAS

Internet

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:

Navegador (IPE, Netscape)Navegador (IPE, Netscape)

GAP

Cliente Pocket PC

WiFi

¿Conexión?

¿Caché?

T

Caché transcodificada

Sí

No

No � Error

Sí

Conversión local / Web

AnalizadorHTTP

GAS

W Internet

Squid

¿Transcodificada?

Transcodificador

¿Actual?

AcaparadorT

Caché transcodificada

SincronizadorCaché servidor

SincronizadorCaché local

Sí

Sí

No

No

Éxito

G

D

L

GAL

MT

MA

Observador

Gestor deDesconexión

Módulos a integrar pertenecientes a Moviware

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.

3. Gestor de Acaparamiento Local (GAL).-

Cuya misión consiste fundamentalmente en dos

cosas:

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

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.

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:

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.

7. Conclusiones

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.

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).

8. Referencias bibliográficas

[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. 22-

25, 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 M-

Learning 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 Paris-

Sorbonne 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.