CENTRO NACIONAL DE INVESTIGACIÓN Y DESARROLLO · Transformador de Contenidos Web para Asistentes...

S.E.P. S.E.I.T. D.G.1.T

CENTRO NACIONAL DE INVESTIGACIÓN Y DESARROLLO T E C N O L ~ G I C O

cenidet TRANSFORMADOR DE CONTENIDOS WEB PARA

ASISTENTES PERSONALES DIGITALES PDAc

T E S I S PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS

EN CIENCIAS DE LA COMPUTACIÓN

P R E S E N T A CLAUDIA SELENE URIARTE CABADA

Director de Tesis M.C. JUAN GABRIEL GONaLEZ SERNA

Co-Director de Tesis DR. VkTOR JESÚS SOSA SOSA

CENTRO DE .INFORMACION DG'Tl SEP CENIDET 0 4 - 0 4 7 7

I CUERNAVACA, MORELOS JUNIO 2004

Centro Nacional de lnvesligacion cenidet y Desarrollo Tecnoiogico Sistema Nacional de Institutos Tecnologicos

. \ N E X O N o . l l

ACEPTACI~N DEL DOCUMENTO DE TESIS M I 0

Cuemavaca. Mor.. a 29 de Abril del 2004

Dr. Rodolfo A. Pazos Rangel Jefe del departamento de Ciencias Computacionales Presente.

At'n: Dr. Gerard0 Reyes Sa1g:ido. Presidente de la Academia de Ciencias Coinputacionales

Xos es yraio coinuiiicarle. que conforme a los lineamientos para la obtención del grado de Maestro en Ciencias de este Centro. y después de' haber sometido a revisión académica la tesis titulada: Transformador de Contenidos Web para Asistentes Personales Digitales PDAs, realizada por la C. Claudia Selene Uriarte Cabada, y dirigida por el M.C. Juan Gabriel González Serna. y habiendo realizado las correcciones que le fueron indicadas, acordamos ACEPTAR el documento final de tesis. así mismo le solicitamos tenga a bien extender el correspondiente oficio de autorización de impresión

Atentamente La Comisión de Revisión de Tesis

M. 6-iL-h. z M.C. Mario Guillén Rodriguez

Revisor Revisor

C.C.P. Subdirección Académica Depanameiiro de Servicios Escolares Directores de tesis Esiiidiante

-&oTfOUC*OO(lE

FORMULARIO C4 AUTORIZACIÓN DE IMPRESIÓN DE TESIS

I ~m~~

TEtS.(777l312 2314.318 7741,FAX(777) 312 2434 EMAIL [email protected]

cenidet ./5""""

Cuemavaca, Mor., a 29 de Abril de 2003.

C. Claudia Selene Unarte Cabada Candidato al grado de Maestro en Ciencias en Ciencias de la Computación Presente

I Después de haber atendido las indicacio es sugeridas por la Comisión Revisora de la Academia de Ciencias Computacionales en rela,'ón z a su trabajo de tesis: Transformador de Contenidos Web para Asistentes Personal? Digitales, me es grato comunicarle, que conforme a los lineamientos establecidos para la obtención del grado de Maestro en Ciencias en este Centro, se le concede la autorización para qu& proceda con la impresión de su tesis.

I

Dedicatorias

Por sei Por su amor, sus

Por ser

César Omac

Por re' Por el

A Dios Por permitirme llegar hasta aquí.

A mis Padres Marcos y Carmen

esoro más maravilloso de mi vida diciones, su apoyo y su corlfianza ,rgullo y mí más grande ejemplo.

A mis Hermanos zrco Antonio y Karime Sirahi

er juntos nuestros primeros pasos ño que me han brindado día a día 'or todo lo que signijkan para mí.

A Emilio

Por iluminar mi corazón.

Agradecimientos Un agradecimiento muy especial a todas aquellas personas que me apoyaron a lo largo de este proyecto. Su amistad, su enseñanza, su dedicación y su ejemplo los llevaré en mí por siempre.

A mis abuelos, por su amor, sus sabios consejos, y por haberme hecho el regalo más valioso de mi vida: mis padres.

A toda mi familia por creer en mí. A pesar de la distancia siempre estuvieron a mi lado, a todos muchísimas gracias!

A la familia Pedrozo Rodríguez por su apoyo desde el primer día, y por todo su cariño.

AI Centro Nacional de Investigación y Desarrollo Tecnológico por darme la oportunidad de realizar este proyecto, y por todo lo que en éste aprendí.

A Cosnet (Consejo del Sistema Nacional de Educación Tecnológica) por el apoyo económico otorgado durante la realización del programa de maesbía.

A la SEP (Secretaría de Educación Pública) por ser parte importante con su apoyo económico para la culminación de mis estudios.

A mi director de tesis, M.C. Juan Gabriel González Serna y mi codirector, Dr. Víctor Jesús Sosa Sosa, por compartirme sus conocimientos y guiarme a lo largo de este trayecto, pero sobre todo, por el valioso tiempo dedicado para que esto fuera posible.

A mis revisores, Dr. Rodolfo A. Pazos Rangel, M.C. Guillermo Cahue Díaz y M.C. Mario Guillén Rodríguez. Gracias por la dedicación a este trabajo, por sus observaciones y sus acertados consejos para mejorarlo.

A todos mis maestros, por brindarme sus conocimientos. AI M.C. José Antonio Zarate Marceleño por ser mi tutor durante mi estancia en Cenidet y por su amistad.

A Anita, un agradecimiento especial por todo su apoyo.

AI personal del Depto. de Servicios Escolares, por estar al tanto de cada uno de nosotros. Sra. Ade, muchas gracias por su amistad!

A todos mis compañeros de generación, Lupita, Marisela, Yanef Mario, Rosario, Alo, Leo, Armando, Nubia, Juan José, Jesús, Emilio, César, Vianey, Edgardo y Roberto. Y a todos mis amigos y compañeros del Depto. de Sistemas Distribuidos.

A Lupita, Leo, Emilio, César y Alonso, por haber estado tan cerca de mí en todo momento, por su amistad, su cariño y su compañía. Por vivir conmigo esta experiencia, gracias ... los llevo en mi corazón por siempre!

A todos, mil gracias!

TABLA DE CONTENIDO

Dedicatonas ............................................................................................................................... Agradecimientos ......................................................................................................................... Tabla de contenido ..................................................................................................................... Lista de figuras .......................................................................................................................... Resumen .....................................................................................................................................

. .

CAP~TULO I . INTRODUCCIÓN . .. 1.1. Introduccion ..................................................................................................................

1.2. Descnpcion del problema ........................ ~ .................................................................... 1.3. Estado del Arte ..............................................................................................................

1.3.1. AvantGo ............................................................................................................. 1.3.2. Webclipping ...................................................................................................... 1.3.3. jTranscoder .........................................................................................................

Aplicaciones ....................................................................................................... 1.4. Objetivo General ........................................................................................................... 1.5. Propuesta de solución ................................................................................................... 1.6. Justificacion .................................................................................................................. 1.7. Alcances y Limitaciones ............................................................................................... 1.8. Beneficios ..................................................................................................................... 1.9. Organizacion del documento ........................................................................................

. . .

1.3.4. Tabla comparativa entre el Mecanismo de Transformación y otras . .

.. . . .

. . .

CAP~TULO II . MARCO TEÓRICO . 2.1. Tecnología de Redes inalámbncas ................................................................................

2.1.1. Ventajas y aplicación de las redes inalámbncas .................................................. 2.1.2. Terminología Inalámbnca .................................................................................... 2.1.3. El estándar IEEE 802.1 lb y Bluetoo th ................................................................

2.3.1. Notebooks ............................................................................................................ 2.3.2. Asistentes Personales Digitales ............................................................................

2.3. El Protocolo HTTP ........................................................................................................ 2.4. Tecnologías para el diseño de Contenido de Web ........................................................

2.4.1. HTML .................................................................................................................. 2.4.2. XML ..................................................................................................................... 2.4.3. XHTML ............................................................................................................... 2.4.4. XSL ......................................................................................................................

2.5. Middleware ...................................................................................................................

2.2. Equipos Portátiles ..........................................................................................................

iv

vi viii

V

X

2 3 3 4 4 5

5 6 6 6 7 7 8

11 11 12 12 13 13 13 14 16 17 17 19 19 21

vi

CAP~TULO 111 . ANÁLISIS Y SOLUCIÓN CONCEPTUAL DEL PROBLEMA . 3.1. Descripción General de la Problemática ....................................................................... 3.2. Diseño General de la Propuesta de Solución ................................................................ 3.3. Esquema General de Operación del Servidor Transformador ......................................

3.3.1. Gestión de la Solicitud de HTTP ......................................................................... 3.3.2. Esquema de Funcionamiento del Sistema Cache ................................................. 3.3.3. Mecanismo de Transformación de Contenidos de Web ....................................... 3.3.4. Gestión de la Respuesta de HTTP al cliente ........................................................

CAPiTULO IV . ARQUITECTURA DEL SERVIDOR TRANSFORMADOR . 4.1. Diagrama de Secuencias del Proceso Operativo del Sistema ....................................... 4.2. Estructura de Clases del Prototipo Intermediario .........................................................

4.2.1. Estructura de Clases del Mecanismo de Transformación .................................... 4.3. Tecnología utilizada: API JAXP ..................................................................................

CAP~TULO V . ANÁLISIS DE RESULTADOS . . . . 5.1. Descnpcion de las Pruebas al Sistema ..........................................................................

5.1 . 1. Recursos Tecmcos utilizados ............................................................................... 5.2. Escenarios de Pruebas ...................................................................................................

5.2.1. Descripción del Primer Escenario del Plan de Pruebas ....................................... 5.2.2. Descripción del Segundo Escenario del Plan de Pruebas ....................................

. . . .

. . 5.3. Descripción del Plan de Pruebas ................................................................................... 5.4. Evaluación Experimental ..............................................................................................

5.4.1. Escenario de Pruebas 1 ........................................................................................ 5.4.2. Escenario de Pruebas 2 ........................................................................................

5.5. Análisis de Resultados Obtenidos ................................................................................

CAPíTULO VI . CONCLUSIONES Y TRABAJOS FUTUROS . 6.1. Conclusiones ................................................................................................................. 6.2, Aportaciones ................................................................................................................. 6.3. Trabajos Futuros ...........................................................................................................

Apéndice A . Glosano ........................................................................................................... Apéndice C . Resultados del servidor Transformador .......................................................... Apéndice B . Gramática del Subconjunto de HTML 3.2 en BNF .................... i ................... Referencias ...........................................................................................................................

23 24 25 26 27 28 32

34 34 37 40

42 42 43 43 43 44 44 44 45 59

62 63 64

65 68 76 81

LISTA DE FIGURAS

Fig . 1.1. Fig . 2 . 1 . Fig . 2.2. Fig . 2.3. Fig . 3.1. Fig . 3.2. Fig . 3.3. Fig . 3.4. Fig . 3.5. Fig . 3.9. Fig . 3.1. Fig . 3.8 Fig . 3.9. Fig . 3.5. Fig . 3.10 Fig . 4.1. Fig . 4.2. Fig . 4.3. Fig . 4.4. Fig . 5.1. Fig . 5.2. Fig . 5.3. Fig . 5.4. Fig . 5.5. Fig . 5.6. Fig . 5.7. Fig . 5.8. Fig . 5.10. Cliente IE (Internet Explorer) bajo la plataforma de Windows 98 ....................

Fig . 5.1 2 . Estructura fisica del documento cacheXML .xml ................................................. Fig . 5.1 3 . Estructura de directorios del sistema Cache ......................................................... Fig . 5.14. Inicialización del sistema Cache con depuración ................................................. Fig . 5.15. Reporte de estado de la Cache para el caso de prueba 4 ...................................... Fig . 5.16. Identificación del dispositivo Pocket PC ............................................................. Fig . 5.17. Resultado de la petición número uno, no almacenada en Cache ........................ Fig . 5.18. Procesamiento de la petición número uno del caso de prueba 4 .......................... Fig . 5.19. Reporte de transformación de contenido de Web y almacenamiento en Cache

de la peticion numero uno del caso 4 .................................................................... Fig . 5.20. Procesamiento de la petición número dos, no almacenada en Cache .................. Fig . 5.21. Reporte de transformación de contenido de Web y almacenamiento en Cache

de la peticion numero dos del caso 4 ..................................................................... Fig . 5.22. Resultado de la petición número dos, no almacenada en Cache ..........................

Fig . 5.9. . ” Fig . 5.1 1 . Inicialización del sistema Cache sin Depuración .................................................

. . . .

. . . .

Arquitectura del prototipo Transformador de Contenidos de Web ...................... 6 Estructura de un documento de XML (libros.xm1) .............................................. 18 Estructura de una hoja de estilo (Libros2. xsl) ...................................................... 20 Vista del documento de XML (libros.xm1) en Internet Explorer ......................... 20 Problemática de múltiples versiones del Contenido de Web ............................... 23 Esquema de la arquitectura general de solución .................................................. 24 Arquitectura general de la plataforma MoviWare ................................................ 25 Operación del servidor Transformador ................................................................ 26 Estructura del documento cacheXML.xm1. .......................................................... 28 Esquema general del mecanismo de transformación ........................................... 28 Transformación de la fase Convertidor de XHTML ........................................... 29 Transformación de la fase Analizador HTML .................................................... 30 Esquema de la fase reformateador ....................................................................... 30 Estructura del documento cacheXML .xml ........................................................... 26 Fase Generador de Hoja de Estilo ........................................................................ 31 Diagrama de secuencias del proceso operativo .................................................... 34 Lista de clases incluidas en el paquete servidor ................................................... 34 Estructura de clases del paquete servidor ............................................................ 35 Estructura de clases del mecanismo de transformación ....................................... 38 Escenario de prueba (Cliente-Internet) ................................................................ 43 . Escenario de prueba (Cliente-Intermediario-Internet) ......................................... 43 Interfaz de configuración de conexiones sin utilizar un servidor proxy .............. 44 Vista original en distintas plataformas ................................................................. 45 Parámetros de configuración para inicializar el servidor Transformador ........... 46 Interfaz del servidor Transformador inicializado ................................................. 46 Configuración de un cliente IE (Internet Explorer) ............................................. 46 Configuración del cliente IPE (Internet Pocket Explorer) .................................. 47 Cliente IE (Internet Exdorer) baio la dataforma de Windows X P ................... 48

48 49 49 50 51 52 52 53 53

54 54

54 55

Fig . 5.23. Reporte de estado de la Cache para el caso de prueba 5 ...................................... Fig . 5.24. Reporte de actualización de Cache en petición uno, almacenada en Cache

Fig . 5.25. Resultado de la petición uno. almacenada en Cache (caso de prueba 5) ............. Fig . 5.26. Salida del procesamiento de peticiones de HTTP ................................................ Fig . 5.27. Reporte de actualización de Cache en petición dos, almacenada en Cache ....... Fig . 5.28. Resultado de la petición dos, almacenada en Cache (caso de prueba 5) ............. Fig . 5.29. Resultados en diversos escenarios - petición http://www.noticiasnet.com .a/ ..... Fig . 5.30. Resultados en diversos escenarios - petición

http:// www.aragonena.com/natural/hongos/index.html ...................................... Fig . 6.1. Prototipo Transformador en la arquitectura de MoviWare ..................................

(caso de prueba 5) ...............................................................................................

56

57 57 58 58 58 59

59 63

ix

http://www.noticiasnet.com

Resumen El acelerado crecimiento en la miniaturización y disponibilidad de componentes de

hardware, así como el desarrollo de las comunicaciones inalámbricas, han sido uno de los

últimos avances más significativos dentro del mundo de la computación. La gran diversidad de

dispositivos móviles que se encuentran en el mercado, como Asistentes Personales Digitales o

PDA, teléfonos celulares, etc., y la notable aceptación que han tenido por parte de los usuarios, han hecho que esta nueva clasificación de dispositivos posea una amplia participación en el

ámbito de la World Wide Web.

Dispositivos de mano equipados con tecnología inalámbrica para obtener una conexión a

Internet, son los que hoy en día están explorando fuertemente los recursos que se encuentran

sobre la misma. Sin embargo, cuentan con características inherentes que les impiden obtener una

navegación eficiente; debido a las reducidas dimensiones de pantalla que los restringe para visualizar grandes cantidades de información, y por consecuencia, para obtener resultados

Óptimos al solicitar el contenido de Web, que de manera original ha sido diseñado para

plataformas convencionales.

Una alternativa de solución al problema que enfrentan estos dispositivos, es tratar el

contenido original que se encuentra en la Web, mediante mecanismos de transformación que

permitan obtener versiones adhoc dirigidas a los dispositivos a los que nos estamos refiriendo. Y de esta manera, lograr que obtengan un mayor desempeño en sus navegadores.

Por tal motivo, en este trabajo de investigación se presenta una solución que nos permite

abordar dicha problemática. La propuesta está basada en una arquitectura de tres capas (cliente-

intermediario-servidor), que permite dar un servicio especial a los Asistentes Personales Digitales. Para esto, se ha construido un servidor intermediario, que ha de atender y gestionar las peticiones de los PDA de una manera muy particular, por io que, se encuentra integrado con un mecanismo de transformación de contenidos de Web, logrando personalizar el contenido

solicitado en tiempo de ejecución, evitando mantener múltiples versiones de un recurso en los servidores, así como la modificación de los mismos para atender a dichos dispositivos.

X

INTRODUCCI~N Capítulo I

Introducción.

En este capítulo se presenta una introducción acerca del panorama de este trabajo, abordando el estado del arte correspondiente, el objetivo, alcances y limitaciones, así como también, los beneficios que trae consigo la realización de este proyecto de investigación.

Página I

Capítulo I INTRODUCCI~N

1.1. Introducción

El crecimiento explosivo de la World Wide Web ha sido acompañado por una proliferación de dispositivos móviles, aunado al desarrollo de medios de comunicación inalámbricos (radio frecuencia, microondas, infrarrojo, etc.). Así que, dispositivos como las computadoras portátiles pequeñas están jugando ,un papel muy importante en la actualidad. Un dispositivo de mano equipado con un navegador y una conexión inalámbrica, proporciona una oportunidad para conectarse a Internet en cualquier momento desde cualquier lugar. Tales capacidades incrementan la utilidad de este tipo de aparatos, ya que permiten tener acceso a numerosos servicios de información, como noticias, entretenimiento, horarios de vuelos, etc.

Se estima que cada día miles de usuarios de internet utilizan la red celular para enviar y recibir varios tipos de datos, y la cantidad de computadoras portátiles y Asistentes de Datos Personales (Palm, Pocket PC, etc.) se está incrementando día a día, creando gran interés en los mercados de computación, debido a que la venta de dichos dispositivos se encuentra en una tendencia ascendente.

Por otro lado, al mismo tiempo que se ha ido expandiendo la utilización de dispositivos de mano, se ha originado un nuevo concepto denominado HotSpot. Los HotSpots son lugares o sitios públicos de alta concentración donde una persona, por cualquier motivo, debe permanecer un lapso de 1 a 3 horas, en donde un usuario podrá disponer de una conexión inalámbrica a Internet mientras está en espera de su vuelo, por mencionar un ejemplo [I]. Esto último, ha venido a consolidar una gran aceptación hacia estos dispositivos, como son los Asistentes Personales Digitales dentro del ámbito de la computación móvil.

Por lo anterior, en la actualidad se ha puesto un interés significativo enfocado a la capacidad que caracteriza a este tipo de dispositivos para acceder a internet. A través de un PDA el acceso es más limitado que por medio de una computadora personal. Y a pesar de que algunos de éstos permiten visualizar cualquier página de Web por medio de enlaces inalámbricos, aún poseen caractensticas inherentes que los limitan a obtener la calidad deseada en comparación a la que obtienen los usuarios de computadoras de escritorio tradicionales.

El desafio evidente es reconocer estas limitaciones y compensarlas inteligentemente mediante la presentación de datos ad-hoc, y/o funcionalidad de navegación para minimizar desempeños negativos que se presentan cuando se intenta desplegar más datos de los que la pantalla puede acomodar. Existen diversos mecanismos que han sido implementados para proporcionar a estos dispositivos una navegación más completa [2, 31, sin embargo, en su mayona se han preocupado por diseñar contenidos de Web a la medida de las pantallas pequeñas de los dispositivos en cuestión, manteniendo esos nuevos diseños almacenados en servidores. Por otro lado, se encuentran soluciones basadas en intermediarios [4, 51; dichas soluciones adoptan diferentes metodologias que tratan la transformación de contenido existente en la red; y se ha analizado que una solución de este tipo basado en intermediario, hace posible la implementación de técnicas de una manera más eficiente, que en un momento dado pudieran resultar más costosas ai situarse del lado del servidor o del lado del cliente.

Página 2

capitulo 1 INTRODUCCIÓN

1.2. Descripción del problema

Hoy en día, existe una gran diversidad de dispositivos PDA con características muy específicas, desde dispositivos con procesadores poco potentes, con unos cuantos megabytes de memoria y una capacidad de despliegue muy limitada, hasta los que poseen procesadores de una mayor capacidad, aumentando la cantidad de memoria y las características de despliegue, con una mejor resolución de pantalla y una mayor cantidad de colores. Sin embargo, aún enfrentan problemas en la navegación por Internet, ya que estos dispositivos portátiles no logran desplegar algunos contenidos de Web adecuadamente, y en algunos otros casos es complicada la manipulación de esas páginas como resultado de sus diseños.

Por io tanto, cada uno de estos dispositivos soporta de forma diferente el contenido de Web existente. Entre las dificultades que enfrentan se tienen, el manejo de objetos dinámicos como CGIs (Common Gateway Interface), cuya ejecución genera ciertos resultados que forman parte de las páginas de HTML que manejan formularios, ai igual que el soporte para scripts de Java. Otra de las dificultades es la manipulación de frames dentro de las dimensiones limitadas de despliegue, ya que restan mucho espacio en la pantalla y se ve afectada la presentación o visualización del conjunto de elementos por los cuales están constituidos.

Varios estudios [6] han mostrado que el tamaño de la pantalla tiene efectos en el desempeño de las tareas. Otros muestran que en pantallas pequeñas se tienen como resultado tiempos de lectura más lentos, así como también, se ha mostrado que implican más interacciones de avance y regreso de páginas.

Por todo lo anterior, se ha observado que una de las limitaciones más relevantes que se presenta en este contexto, es el área de despliegue que poseen estos dispositivos, la cual es generalmente más estrecha y más corta que cualquier pantalla de una computadora de escritorio. Por tal motivo, la selección de fuentes de caracteres para esas dimensiones es más restrictiva, esto significa que se puede presentar menos información en una sola pantalla, y es probable que el texto y las áreas de imágenes sean mucho más pequeños en comparación con las de pantallas de una PC tradicional. Por lo tanto, aquí radica la problemática a tratar, así que se hace necesario implementar mecanismos de transformación de contenidos de Web que conlleven a mejorar la capacidad de los PDAs para obtener la calidad deseada en cuanto a los servicios de Internet proporcionados sobre plataformas tradicionales.

1.3. Estado del arte

Hay varias soluciones a este problema de acceso a la Web mediante múltiples plataformas. Una de éstas, la más simplista y frecuente, es simplemente que los usuarios con dispositivos PDA restrinjan el acceso a la Web sólo a páginas diseñadas para pantallas pequeñas o aprovechar lo mejor de las páginas grandes en sus dispositivos.

Trabajos recientes basados en servidores proxy (Berkeley Pythia proxy [7] y Transend [8]) proporcionan compresión dinámica de contenidos de Web para mejorar la velocidad de transmisión en dispositivos inaíámbricos. Otra solución más simple es diseñar páginas de Web

Página 3

Capítulo I INTRODUCCION

ad-hoc, es decir, múltiples versiones de la misma página, lo cual implica una labor intensa, costosa y prohibitiva para la gran cantidad de páginas de Web disponibles en la WWW. A continuación se describen algunas de las soluciones analizadas.

1.3.1. AvantGo

Es un sistema de navegación creado por I'a compañía AvantGo, cuyo objetivo es enviar contenidos de Web a PCs de bolsillo. En realidad no son más que páginas de Web diseñadas con algunas características especiales.

Los requerimientos para tener acceso al servicio de AvantGo son los siguientes:

Una cuenta en AvantGo.

Este servicio se puede configurar en múltiples plataformas, así que swequiere de un dispositivo portátil como Palm, dispositivos con Windows CE o móviles WAP. Una PC de escritorio con una sincronización configurada a través de Activesync' y conexión a internet disponible.

Los usuarios de AvantGo pueden manejar las configuraciones de sus cuentas, lo cual incluye, configuración de canal, administración de claves de acceso, bitácoras de sincronización y software actualizado de descarga. Esta aplicación permite la configuración de canales personalizados que se descargan desde la conexión con la PC cada vez que se sincroniza con el PDA. Esto posibilita volcar datos al dispositivo y acceder a ellos offline hasta que se vuelva a sincronizar éste.

Su funcionamiento es sencillo, tan sólo se descarga el software correspondiente al dispositivo portátil a utilizar, se instala siguiendo los pasos que se indican a través de la Web, debiendo tener sincronizada la PC de bolsillo en todo momento para poder realizar la configuración adecuadamente. Una vez que se lleve a cabo la configuración y el proceso de sincronización haya finalizado, se podrá tener acceso a la información sobre el dispositivo móvil.

1.3.2. Webclipping

Las aplicaciones de Web Clipping (extracción de información de las páginas Web) para Palm OS 3.5, permiten acceder a la información que más interesa de forma rápida y eficiente, a través de una conexión inalámbrica que evita la pérdida de tiempo que suponen la complejidad de los gráficos o la información no requerida. Hay disponibles muchas aplicaciones de Web Clipping que proporcionan noticias, cotizaciones de bolsa, horarios de vuelos, mapas de carreteras, partes meteorológicos y muchos otros datos de interés.

Activesync. Software que hace posible la comunicación entre una computadora personal y un dispositivo PDA, I permitiendo la transferencia de información de una a otra

Pagina 4

Capitulo 1 INTRODUCCION

Para entender cómo funcionan, se han analizado los componentes que integran este tipo de aplicaciones: PQA y Web Clipping.

Una PQA (Palm Query Application), es un tipo especial de aplicación para los dispositivos Palm VI1 que le permite al usuario interactuar inalámbricamente con el contenido de Web. Una PQA lleva el contenido estático en una aplicación que puede ser instalada dentro de un dispositivo Palm VII. Los enlaces en un documento PQA pueden referirse a otras páginas dentro de la aplicación, a documentos o scripts residentes en un servidor de Web disponible. Las páginas que no se encuentran dentro de la PQA, naturalmente, son resultado de una solicitud de HTTP inalámbrica.

Finalmente. Web Cliuuin~! es el resultado de las solicitudes enviadas desde la POA al II - .

servidor de Internet. Tanto la Palm Query Application como Web Clipping, son escritos en HTML.

1.3.3. jTranscoder

jTranscoder es un convertidor de HTML. Este permite convertir fácilmente archivos de HTML en archivos de WML, visibles en teléfonos celulares habilitados para la Web, y archivos Web Clipping en Palm VI1 Pilots2. Se puede traducir un solo archivo de HTML a la vez, mediante la selección de dicho recurso accesible desde el sistema de archivos de la PC, o traducir un sitio de Web completo mediante la especificación de la URL de dicho sitio. jTranscoder guarda el resultado de la traducción dentro de archivos.

Cuando se están convirtiendo los archivos de HTML al formato de Web Clipping, se podrá utilizar la herramienta Webclipping Builder de Palm inc. para construir una aplicación PQA de los archivos resultantes e instalarlos dentro de la Palm Pilot. Por otro lado, cuando se trata de convertir un sitio de Web completo, jTranscoder provee un listado de los enlaces que se tradujeron, para informar acerca del directorio y la estructura de archivos del resultado de la conversión y los enlaces de HTML que se han visitado durante la transformación.

1.3.5. Tabla comparativa entre el mecanismo de transformación y otras aplicaciones

Ahora se muestra un concentrado de información, comparando las tecnologías analizadas y el prototipo Transformador desarrollado en este trabajo.

Pilot. Tipo de dispositivo de mano con sistema operativo Palm. 2

Página 5

Capitulo I INTRODUCCION

1.4. Objetivo general

El objetivo general de este trabajo de investigación, es el desarrollo e implementación de componentes middleware para la transformación, eliminación o retención de objetos contenidos en páginas de Web, las cuales fueron diseñadas originalmente para plataformas convencionales. Y ahora, éstas son solicitadas por dispositivos de mano con pantallas pequeñas, por lo que se requiere de un mecanismo adicional que permita visualizar dichas páginas de acuerdo a las dimensiones de despliegue que caracterizan a los dispositivos PDA.

En resumen, el objetivo es desarrollar un intermediario que proporcione servicios de transformación de contenidos de Web para Asistentes Personales Digitales en un ambiente de red inalámbrico.

1.5. Propuesta de solución

Para solucionar la problemática planteada se ha de conformar una plataforma middleware, es decir, una arquitectura de tres capas cuya integración está dada por los dispositivos portátiles, un intermediario y los servidores de Web.

Con dicha implementación se elimina el proceso de rediseño de contenidos de Web, lo cual implicaría mantener múltiples versiones de una página para cada tipo de dispositivo PDA que la solicite. Por lo tanto, con la técnica de omisión, transformación y retención en tiempo de ejecución, se obtendrán los formatos adecuados sin necesidad de mantener información duplicada. En teoría, el contenido de páginas de Web estará disponible para el usuario sin importar qué dispositivo esté utilizando en ese momento. Por lo tanto. la arquitectura para implementar esta solución se ve reflejada en la figura 1 . 1

........................................ ~ ..................................................................... ~ ~ . . . ~ ~ ......... Fig. 1.1 Arquitectura del prototipo Transfomador de Contenidos Web

1.6. Justificación

Es importante resaltar que en la actualidad se está presentando un crecimiento exponencial en lo que se refiere a la participación de dispositivos PDA en la WWW. Por lo que se hace sumamente necesario implementar mecanismos especiaies para que estos dispositivos lleven a cabo una navegación eficiente en la Web, teniendo acceso a los recursos

Página 6

INTRODUCCI~N Capitulo I

que se encuentran disponibles en Internet, y no solo a los recursos que cuentan con diseños especializados para éstos en particular.

Con el fin de evitar cambios drásticos en la infraestructura con la cual se opera hoy en día en Internet, es posible implementar la solución en una arquitectura de tres capas, donde la funcionalidad requerida esté situada en un intermediario, y en este caso integrado con servicios de transformación de contenidos de Web para dispositivos PDA.

1.7. Alcances y limitaciones

Los alcances y limitaciones establecidos para el desarrollo de este proyecto, se encuentran listados en los siguientes puntos:

Transformación, eliminación o agrupación de los siguientes elementos contenidos en archivos de HTML:

a. gráficos, b. tablas, c. texto, d. títulos, e. ligas.

Implementación de módulos de transformación de páginas de HTML, de acuerdo a las restricciones definidas en el punto anterior.

Los dispositivos considerados para operar sobre el intermediario construido, son los que se encuentran bajo la plataforma de los Pocket PC, es decir dispositivos que trabajan sobre sistemas operativos como Windows CE y Pocket PC 2002.

La problemática que se ha enfrentado es bastante extensa, por esta razón se ha considerado la transformación de los elementos básicos que son soportados e interpretados sin inconveniente alguno por parte de los navegadores de Web a los que se hace referencia, debido a las características y limitaciones que poseen. Es por eso que se ha definido un subconjunto del lenguaje HTML 3.2, sobre el cual operan las plataformas de estos dispositivos, como base para marcar los limites de este trabajo de investigación.

1.8. Beneficios

De acuerdo a los elementos planteados anteriormente y al análisis de resultados, los beneficios que se obtienen con la implementación de la metodología desarrollada son los siguientes:

Página 7

INTRODUCCI~N Capitulo I

Evitar el diseño de contenidos de Web en formatos múltiples para una plataforma en oarticular. Es decir, no es necesario mantener versiones diversas del contenido de Web, lo cual trae consigo el ahorro de recursos de cómputo

Con el empleo de técnicas de reformate0 de los objetos contenidos en páginas de Web, se obtiene la disponibilidad deseada y el formato adecuado para los dispositivos portátiles que la solicitan. Por lo anterior el usuario obtiene un mejor desempeño en SU dispositivo PDA.

El reformate0 de la información es transparente para el usuario, de tal forma que no es necesario reconfigurar sus navegadores constantemente para visualizar la información contenida en páginas de Web diseñadas para plataformas PC mientras navegan en Internet.

La arquitectura cliente-intermediario-servidor adoptada evita la modificación de los servidores de Web existentes. Por lo que se considera que agregar un servidor intermediario especializado proporciona varios beneficios en cuanto a desempeño y seguridad.

Con el desarrollo de este trabajo se asimiló e implementó tecnología de frontera en aplicaciones de cómputo móvil basadas en plataformas PDA, lo cual se ha considerado es un área de investigación y aplicación de gran impacto en diversos sectores, como la industria, la educación, etc.

1.9. Organización del documento

El documento de tesis está organizado en seis capítulos, y en cada uno de ellos se describe la parte correspondiente a cada una de las etapas exploradas a lo largo del trabajo de investigación realizado.

Capítulo 1. En esta fase, se presenta una breve introducción al tema de investigación, abordando la problemática en cuestión, así como también, se plantean el objetivo general, los alcances y limitaciones, justificación y los beneficios, a manera de situarlos sobre el contexto del trabajo desarrollado.

Capítulo 2. Aquí se definen las diversas tecnologías que fueron abordadas para la realización del proyecto, por lo que forman parte integral de la terminología que se utiliza en la totalidad de este documento.

Capítulo 3. En este capítulo, se describe el análisis realizado correspondiente a la propuesta de solución, con el fin de establecer una metodología para la transformación de contenidos de Web. Por lo tanto, se aborda la solución conceptual del problema.

Capítulo 4. Aquí se muestra la arquitectura del sistema, definiendo la arquitectura de clases y la descripción de los elementos que la integran.

Página 8

! I

Capitulo I I I I N T R O D U C C I ~ N I I I I I ' Capítulo 5. La etapa de evaluación del sistema se dantea en este capítulo, donde se

muestra el plan de pruebas diseñado. con dl objetivo de verificar la funcionalidad del

Capítulo 6 . Finalmente se presentan las conclusiones y los trabajos futuros que se

I prototipo. I

pueden experimentar posteriormente en esta línka de investigación.

I

I

i Página9

I MARCO TEÓRICO Capítulo I I

Marco Teórico. Los conceptos básicos o elementales que fungen como parte de los fundamentos que

integran este trabajo se presentan en este capítulo, entre ellos, el ambiente de redes inalámbncas, la clasificación de dispositivos portátiles, las tecnologías para el diseño de contenidos de Web, etc.

Página 10

MARCO TEÓRICO Capítulo I I

2.1. Tecnología de redes inalámbricas

Las redes inalámbricas han facilitado la operación en lugares donde la computadora no puede permanecer en un solo lugar, como en almacenes, fábricas 0 en oficinas que se encuentren en varios pisos. A pesar de esto, el objetivo fundamental de las redes WLAN (Wireless Local Area Network) es el de proporcionar las facilidades no disponibles en 10s sistemas cableados y formar una red total donde coexistan los dos tipos de sistemas.

En particular las redes WLAN también conocidas como IEEE 802.1 1 utilizan la banda ISM (industrial Scientific and Medical). Esta banda incluye los rangos de frecuencia de 902 a 928 MHz y de 2.4 a 2.484 GHz, los cuales son rangos libres, por lo que no es necesaria la licencia o compra de permisos [9].

Por otro lado, la gran rapidez con la que Internet se ha expandido y popularizado en los Últimos años, ha supuesto una revolución muy importante en el mundo de las comunicaciones, llegando a causar cambios en muchos aspectos de la sociedad. En la actualidad, el intercambio de información sobre las redes se está dando en gran escala a través de equipos portátiles, el cual incrementa día a día, razón por la cual se está creando un gran interés en los mercados de computación, y sobre todo en el de redes inalámbricas.

2.1.1. Ventajas y aplicaciones de las redes inalámbricas

Una de las ventajas principales que proporcionan las redes inalámbricas, es la eliminación del cable, lo cual representa una variante muy importante sobre las redes tradicionales.

Son fáciles de instalar, por lo que son ideales para empresas que no desean romper paredes, ni la estructura del edificio para instalar los cables o que se encuentran en oficinas no aptas para realizar la instalación de los mismos.

Los usuarios de ordenadores portátiles pueden desplazarse dentro de la empresa sin dejar de estar conectados a la red o a Internet en todo momento.

Son útiles para mejorar la comunicación entre empleados, ya que pueden trabajar con mayor facilidad en proyectos compartidos al poder llevarse sus ordenadores portátiles a reuniones, congresos, etcétera.

Debido a lo anterior, todos los componentes de una red inalámbrica pueden seguir utilizándose al ser removidos del lugar donde fueron instalados, una vez que se requiera cambiar la ubicación de la red.

Las aplicaciones más típicas de las WLAN que se encuentran actualmente son las siguientes:

0 4 - 0 4 7 7 Página 11

MARCO TEÓRICO Capitulo I I

1. Implementación de redes de área local en entomos donde la solución cableada es inviable, como por ejemplo, en sitios de cableado dificil o prohibido, como museos, fábricas, etc

2. Posibilidad de reconfiguración de la topología de la red sin añadir costos adicionales, para entomos cambiantes que necesitan una estructura de red flexible.

3. Generación de grupos de trabajo eventuales y reuniones ad-hoc.

4. Interconexión de varias LAN que se encuentran en lugares fisicos distintos (conexiones entre edificios).

2.1.2. Terminología inalámbrica

Al mismo tiempo que la tecnología inalámbrica ha ido revolucionando en el ámbito de las redes, se ha dado origen a nueva terminología dentro del mismo contexto [lo]:

HAN (Home Area Network). Una HAN es una red contenida dentro del hogar del usuario que conecta los dispositivos digitales, desde múltiples computadora y dispositivos periféricos hasta teléfonos, grabadoras de video, televisores, juegos de video, sistemas de seguridad domésticos, aparatos “inteligentes”, faxes y otros dispositivos digitales que son conectados en red. PAN (Personal Area Network). Una PAN enlaza dispositivos que se encuentren muy cerca unos de otros (alrededor de 10 metros); remplazando los cables USB (universal serial bus); éstas son redes espontáneas o “ad hoc”, y a diferencia de otros tipos de redes inalámbricas, las PANS no necesitan una infraestructura [I I]. Así, dispositivos de todo tipo, desde teléfonos y portátiles hasta impresoras, e incluso aparatos electrónicos domésticos tales como T V s y estéreos, son perfectamente adecuados para las redes “ad hoc”. WLAN (Wireless Local Area Network). Una WLAN lleva la conectividad a lo largo de un sitio, tal como una universidad o un campus corporativo o una red doméstica, colocando “puntos de acceso”, estaciones de base fija con un alcance de alrededor de 500 pies, a lo largo de la infraestnictura existente. CAN (Campus Area Network). Los nodos de esta red se encuentran dentro de un área geográfica limitada, como un campus universitario o un área militar.

2.1.3. El estándar IEEE 802.11b y Bluetooth

Estos protocolos inalámbncos de corto alcance son mutuamente excluyentes. La realidad es que los mercados para IEEE 802.11b y Bluetooth son claramente diferentes. Los dos protocolos sirven radicalmente a diferentes funciones y raramente, alguna vez, se confrontarán para el mismo tipo de uso.

Página I2


Gracias a los orígenes de la PC y a la alta velocidad de transferencia de datos, el estándar IEEE 802.1 1 b ha llegado a ser el estándar indiscutible para las WLANs de hoy. Por otra parte, el alto costo, el tamaño del hardware más grande y el consumo de potencia más alta, dan a Bluetooth la ventaja en las PAN. Entre las características que distinguen a estos estándares se mencionan las siguientes [I 11:

Bluetooth:

El chip Bluetooth establecido es pequeño y económico ( comparado con el IEEE 802.1 1 b) Bluetooth se encontrará en dispositivos tales como ratones de computadoras,

Posee un rango de acción de 10 metros. A esta distancia tiene una velocidad de transmisión de 723 kbps. Su punto fuerte es el bajo consumo de energía.

teléfonos, laptops, handhelds, cámaras, etc.

IEEE 802.1 Ib:

Significantemente, 802.1 1 b posee una velocidad de transferencia de datos más rápida que Bluetooh (1 1 Mbps a unos cientos de metros, hasta 22 Mbps y recientemente 54 Mbps). IEEE 802.11b está en un sitio especifico, esto es, requiere una infraestructura, tal como Ethernet. Con respecto a Bluetooth consume más energía y por eso es más apto para notebooks y menos apto para celulares.

2.2. Equipos portátiles

Porfúfil significa pequeño y ligero. Una computadora portátil es una computadora. lo suficiente pequeña para llevar cargando. Las computadoras portátiles se clasifican de la manera que se describe en las siguientes subsecciones [IO].

2.2.1 Notebooks

Una computadora personal extremadamente ligera. Aparte del tamaño, la diferencia principal entre una computadora notebook y una computadora personal es el despliegue de pantalla. Sin embargo, su costo es casi dos veces más comparado con el costo de una PC.

2.2.2 Asistentes personales digitales

Una computadora portátil que es lo suficiente pequeña para sostenerla en la mano. Aunque son sumamente cómodas para llevar cargando, no han reemplazado a las notebooks

Página 13


debido a sus teclados y pantallas pequeñas. Las computadoras hand-held' mas Populares Son aquéllas específicamente diseñadas para suministrar funciones PIM (Manejo de Información Personal), tales como agenda y libreta de direcciones.

PDA. Es un Asistente Personal Digital, un dispositivo hand-held que combina cómputo, teléfonoifax, y características de redes. Un PDA típico puede funcionar como un teléfono celular, transmisor de fax y como organizador personal. A diferencia de las computadoras portátiles, la mayoría de los PDAs al inicio estaban basados en pluma. Algunos PDAs también pueden reaccionar a entrada de voz. Los PDAs de hoy en día están disponibles tanto en versiones de teclado como de pluma electrónica.

o Palmtop. Una computadora pequeña que literalmente se adapta a la palma de la mano. Comparadas con las computadoras de tamaño real, las palmtops son rigurosamente limitadas, pero prácticas para ciertas funciones tales como guía telefónica y agendas, aunque recientemente se le han añadido nuevas características que las hacen más completas.

o

Debido a su tamaño, la mayoría de estos dispositivos no incluyen unidades de disco. Sin embargo, muchas contienen ranuras PCMCIA y Compact Flash (CF), en las cuales se pueden insertar unidades de disco, módems, redes inalámbricas, memoria y otros dispositivos. Por lo anterior se identifican las características que permiten clasificar a los PDAs, entre ellas se tienen, despliegue de pantalla, batería, memoria, tamaño, peso, entrada de información, sistema operativo, costo, etc.

Entre los sistemas operativos para PDAs están Palm OS, Windows CE, Epoc, y recientemente Linux, cada una de estas plataformas ofrece una interfaz gráfica diferente y una multitud de aplicaciones; todo orientado a conseguir la mayor facilidad, personalización y velocidad en su uso.

2.3. El Protocolo HTTP

HTTP es el protocolo de la Web. Es decir, las normas según las cuales se transmiten los recursos de la World Wide Web entre las aplicaciones que acceden a ésta. Estos recursos pueden ser documentos de HTML, imágenes, ficheros de música, etc.

La comunicación tiene lugar a través del envío de mensajes. El cliente (normalmente un navegador) envía un mensaje de petición al servidor, y éste devuelve un mensaje de respuesta, que normalmente contiene el recurso requerido por el cliente. La estructura de estos mensajes es la siguiente:

Una línea inicial, que es diferente según que el mensaje, sea de petición o de respuesta.

Hand-held. Ordenador pequefio de bolsillo, típicamente la mitad de una hoja de papel. Permite tareas típicas de I un ordenador personal, entre ellas, conexión a Internet.

Página 14


. Cero o más líneas de encabezado. . Una linea en blanco. Opcionalmente, un cuerpo de ,mensaje (por ejemplo, un archivo, los datos de un formulario, etc.).

el de un mensaje de petición, la línea inicial tiene la siguiente esamura:

Método - Identificador del recurso - versión de HTTP.

Por ejemplo:

Ahora, las lineas de encabezado dan información sobre el mensaje o sobre el objeto contenido en el cuerpo del mensaje. Cada encabezado, que ocupa una línea, tiene la estructura Nombre del encabezado: valor. HTTP 1 .O define 16 encabezados, y HTTP 1.1 define 46.

GET /index.html HTTP/I . I

Los encabezados que pueden aparecer en las peticiones de HTTP del cliente son los siguientes:

Accept. Campo utilizado para especificar tipos MIME aceptados por el cliente. El carácter * se usa para agrupar tipos media dentro de un rango.

Aufhorizafion. Clave de acceso que envía un cliente para acceder a un recurso de uso protegido o limitado.

From. Campo opcional que contiene la dirección de correo electrónico del usuario del cliente Web que realiza el acceso.

If-Modi$ed-Since. Permite realizar operaciones GET condicionales, en función de si la fecha de modificación del objeto requerido es anterior o posterior a la fecha proporcionada.

User-agenf. Cadena que identifica el tipo y versión del cliente que realiza la petición.

En el caso de un mensaje de respuesta, la línea inicial (Stufus Line) tiene la siguiente estructura:

Versión de HTTP - Código de estado de respuesta - Frase explicativa.

HTTPll . I 200 OK Por ejemplo:

Los encabezados que los servidores de Web utilizan en sus respuestas de HTTP se mencionan a continuación:


~ l [ ~ ~ Informa de 10s comandos de HTTP opcionales que se pueden aplica sobre objeto al que se refiere esta respuesta.

Expires Fecha de expiración del objeto enviado.

Last-Modified Da la fecha de la última modificación del recurso servido (hora GMT), y es útil para las caches @ara ahorrar consumo de ancho de banda). E.jemplo:

Last-Modified: Sat, 16 Jun 2001 23:15:08 GMT

Server. Identifica el programa utilizado como servidor. Ejemplo:

Server: Apache/l.3.12 (Unix)

JVWW-Autenticate. Cuando se accede a un recurso protegido o de acceso restringido, el servidor regresa un código de estado 401, y utiliza este campo para informar de los modelos de autentificación válidos para acceder a este recurso.

Entre los códigos de respuesta que envían los servidores de Web se tiene: el código 200 significa que la petición se ha servido con éxito. Otros códigos típicos son el 404 (el recurso pedido no existe), o el 500 (error inesperado en el servidor). La lista completa de códigos se puede encontrar en la especificación del protocolo [i2].

Las características que diferencian a la versión 1 . I de la versión 1 .O del protocolo HTTP son algunas de las siguientes [13]:

Conexiones persistentes: No se cierra la conexión tras el envío de cada parte de una página.

Peticiones simultáneas: Se puede realizar más de una petición al servidor de Web, mediante una sola conexión TCP.

Nuevos métodos: Aparte del GET, POST y HEAD de HTTP 1.0, se suman PUT, COPY, DELETE, TRACE, OPTIONS y otros más.

Por lo tanto, el protocolo HTTP (HyperText Transfer Protocol) ha hecho posible el poder interactuar con Internet, de tal manera que todos, como usuarios de la red, puedan disponer de los recursos que se encuentran en la misma.

2.4. Tecnologías para el diseño de contenido de Web

AI igual que la proliferación de dispositivos portátiles, desde la aparición de la World Wide Web, se han desarrollado lenguajes de marcado para diseñar la información que se

Página 16


encuentra en Internet. Existen diferentes lenguajes de marcado para representar documentos sobre la red. Estos lenguajes de marcado no difieren mucho de sus predecesores, pero tienen características que les permiten desempeñarse en diferentes contextos, como los que a continuación se describen.

2.4.1. HTML (HyperText Markup Language)

HTML es un lenguaje simple de indicación de formato, utilizado para crear documentos en hipertexto, así que facilita la representación visual de la información sobre Internet [14]. su facilidad de uso hizo a HTML el lenguaje idóneo para compartir información en la Web, y fue así hasta hace un tiempo.

Debido a la expansión de Internet y a la flexibilidad que el lenguaje había venido proporcionando a los diseñadores de páginas de Web y a los propios navegadores, para estructurar e interpretar los documentos respectivamente, además de la necesidad de las empresas y particulares por algo más que imágenes y texto estáticos, ocurrió una sucesión mareante de tecnologías tendientes a añadir interactividad a la Web. Por lo tanto, HTML se expandió y adaptó para hacer cosas para las que no estaba destinado. Por esta razón, se ha dado origen a nuevas tecnologías que persiguen en un futuro la estandarización de la World Wide Web.

2.4.2. XML (Extensible Markup Language)

XML corresponde a una tecnología emergente propuesta por la W3C (World Wide Web Consortium), consorcio de empresas dedicado a desarrollar estándares para la Web.

XML es un lenguaje de marcas basado en texto, que se está convirtiendo rápidamente en el estándar para el intercambio de datos en la Web. Igual que en HTML, se identifican los datos usando etiquetas (identificadores encerrados entre ángulos, tales como c...>). En conjunto, las etiquetas son conocidas como "marcas" [15].

AI contrario de las etiquetas de HTML, las etiquetas de XML dicen lo que significan los datos, en vez de cómo se m o s t r h . Donde las etiquetas de HTML dicen algo como "muestra este dato en negrita" ( ... a>), una etiqueta de XML actúa como un nombre de campo en un programa., es decir, poner una etiqueta a un dato que lo identifica (por ejemplo: ... 4autor>).

Un documento de XML tiene dos estructuras: una lógica y otra física. Físicamente, el documento está compuesto por unidades llamadas entidades. Cada documento comienza con una entidad documento, también llamada raíz. Lógicamente, el documento está compuesto de declaraciones, elementos, comentarios e instrucciones de procesamiento, todos los cuales están indicados por una marca explícita. Los documentos de XML se dividen en dos grupos: documentos bien formados y documentos válidos.

Pagina I7


Bien formados. Son todos los que cumplen las especificaciones del lenguaje respecto a las reglas sintácticas. De hecho los documentos de XML deben tener una estructura jerárquica muy estricta, y los documentos bien formados deben cumplirla, mi lo muestra la figura 2.1. Las especificaciones de XML implican lo siguiente:

O Estructura jerárquica de elementos. o Etiquetas vacías. O Un solo elemento raíz. o Valores de atributos. o Tipos de letras, espacios en blanco.

Válidos. Además de estar bien formados, siguen una estructura y una semántica determinada por un DTD2: sus elementos y sobre todo la estructura jerárquica que define el documento, además de los atributos, todo debe ajustarse a lo que el DTD indica.

~ c7xrnl version="l.O standalone="no"7> i i clOOCiYPE LIBROS SYSTEM "Libros.dtd>

c?xrnlstylesheet hrei="LibrosZ.xsl" type="textlxsl"?> XML AI descubierto4TlTULO> Michael Momson cPREC10~450.00c/PREClO> cTITULO>Java y XMLGITULO> cAUTOR>Brett McLaughlins/AUTOR> 350.M)dPREClO> C/LIBRO> Sistemas de Bases de Datos C. J. DateUAUTOR> 220.00c/PRECiO> clLIBRO> ULIBROS> ..... . .... - .... ..... -- - ....

Fig. 2.1 Estructura de un documento de XML (libros.xrnl)

Por lo anterior, XML es un metalenguaje que permite definir lenguajes de marcado adecuado a usos determinados. Este lenguaje deja a los desarrolladores definir sus propios elementos de marcado, dando una mayor flexibilidad para personalizar los documentos de Web.

Por citar un ejemplo práctico, para un matemático la única posibilidad de poner una fórmula en la Web es crear la fórmula en algún programa, sacarle una "foto", es decir, tomar sólo una imagen de la fórmula y ponerla en su página. Esto significa que otro matemático no puede tomar directamente la fórmula o ecuación, copiarla de la página y pegarla en algún software de'álgebra, cálculo o gráficos para analizarla. XML ha venido a solucionar esto, Ya

' DTD (Document Type Definition). Proporciona la gramática para una clase de documentos XML.

Página 18

MARCO TEÓRICO Capltulo I1

que se ha creado un lenguaje de marcadores matemáticos llamado MathML (Mathematics Markup Language). De esta forma, existen otros lenguajes como CML (Chemical Markup Language), con lo cual se han logrado simplificar tareas de diversas áreas.

2.4.3. XHTML (Extensible HyperText Markup Language)

XHTML es una reformulación de HTML que cumple con las restricciones impuestas por XML. Este lenguaje ha sido creado como un paso hacia el objetivo de estandarizar el marcado para la Web, y lograr que sea compatible con XML.

XHTML fue introducido para servir como un puente o una transición de las tecnologías más antiguas (tales como las incompatibles variaciones de HTML) a tecnologías más nuevas, como lo es XML [16]. Los objetivos principales de XHTML son crear documentos que obedezcan las reglas de sintaxis de XML, y enfrentar las incompatibilidades de HTML en los principales navegadores de Web.

Un documento de XHTML utiliza las mismas etiquetas que un documento de HTMLI4 con la diferencia de que es un documento de XML bien formado. Las reglas que se siguen para crear un documento de XHTML válido son las siguientes [ 171:

1 .

2. 3. 4. 5. 6.

Declarar tipo de documento:

MARCO TEORICO Capitulo II

~ .................................................................................................................................................................. ............................................................ : *body>

ctr bgcolo~-"white"> Clh>TltUlO4th> dh>AutorUih> *h>PrecioUth>

ctd>cxsl:value-of select="TITULOPUtd> ctd>cxsl:value-of select="AUTOR/x/tdtd> ctd>cxsl:value-of select="PRECIO"/>Uld>

Ulbodyp i j UBODY2 F 4 H T M b j Uxsl:ternplate> i Uxsl:stylesh%aD

Fig. 2.2 EStNClura de una Hoja de Estilo (Libros2.xsl)

Finalmente, por un lado se tiene la estructura de los datos en un documento de XML (1ibros.xml) mostrado en la figura 2.1, y por otro, el formato que se le dará a esa estructura a través de una hoja de estilos (Libros2.xsl).

El resultado del procesamiento de ambas tecnologías se aprecia en la figura 2.3. En esta figura se muestra la página de Web obtenida.

- /Sistemas de Bases de Datos /C. J. Date --------------------

___- ~ Fig. 2.3. Vista del documento de XML (libros.ml) en Internet Ewlorer

Página 20

Capitulo I I MARCO TEÓRICO

2.5. Middleware

Como es evidente, brindar la conectividad de Internet a dispositivos inalámbricos requiere de tecnologías innovadoras, y nuevos estándares para llevar información a usuarios de dispositivos portátiles sin importar su ubicación y cómo estén conectados. Esto representa un reto debido a la inimaginable variedad de dispositivos, estándares y aplicaciones que se encuentran disponibles hoy en día. Por la razón anterior, se han desarrollado e implementado plataformas que permitan la interacción con la tecnología de Internet. Entre ellas se encuentra el middleware.

El término middleware se describe como una capa de software ubicada entre el sistema operativo y las aplicaciones distribuidas que interactúan vía la red. Esta infraestructura facilita la interacción entre módulos de software distribuido. El proporcionar una definición M c a ai término middleware es muy complicado, ya que sus definiciones comparten un problema común: dependiendo del ambiente de la aplicación, las opiniones difieren acerca de cuáles son los componentes que comprenden el middleware.

La función principal de una capa middleware es ocultar la complejidad del ambiente de red aislando a las aplicaciones del manejo explícito del protocolo, desasociando memoria, replicación de datos, fallas de la red, y paralelismo. Adicionalmente, el middleware enmascara la heterogeneidad de plataformas de cómputo, sistemas operativos, lenguajes de programación y tecnologias de red que facilitan la programación y administración de aplicaciones [I 91.

CENTRO DE INFORMACION DG'T\ SEP CENIDET

Página 2 I

Capitulo 111 ANÁLISIS Y SOLUCI~N DEL PROBLEMA

Análisis y Solución Conceptual del Problema.

En este capítulo se lleva a cabo un análisis más detallado de la problemática que se está abordando en este proyecto de investigación. Así como también, se describe la metodología de solución correspondiente a la transformación de contenidos de Web.

Pggina 22

Capitulo 111 ANÁLISIS Y SOLUCIÓN DEL PROBLEMA

3.1. Descripción general de la problemática

La dificultad con la que se enfrentan los dispositivos portátiles de mano o Asistentes Personales Digitales para navegar en Internet, conlleva a replantear la manera de proporcionarles los recursos que se encuentran disponibles dentro de la World Wide Web, debido principalmente a los aspectos que se mencionan a continuación:

En la Web existen millones de recursos que no han sido originalmente diseñados para este tipo de dispositivos, y que actualmente, están siendo solicitados por éstos, sin obtener un buen desempeño en lo que a navegación se refiere.

Actualmente, en su gran mayoría, los servidores de Web pueden identificar el tipo de dispositivo que está realizando una petición por un recurso que éstos poseen, pero no están preparados para personalizar la respuesta en tiempo de ejecución y servirles el contenido de Web solicitado.

Por otro lado, los servidores de Web que hoy en día están personalizando la entrega de su contenido, adoptan la estrategia de diseñar previamente los recursos con características especiales para dispositivos con pantallas pequeñas. Esto hace que se vaya creando una duplicidad de recursos en la red, con lo cual se tienen que mantener diferentes versiones de una misma página de HTML, lo que puede resultar costoso, en cuanto al consumo de recursos de los propios servidores. Esto se puede apreciar en la figura3.1.

.........................................

.....................

.... - ..... - Fig. 3.1. Problemática de múitiples versiones del contenido Web

Lo anterior refleja la necesidad que se presenta alrededor de este contexto, lo que conlleva a establecer estrategias de transformación del contenido original de la Web, teniendo que considerar algunas variantes, como por ejemplo, el lugar apropiado para establecer un mecanismo de transformación, ya que se trata de alterar lo menos posible la arquitectura sobre la cual opera un usuario en la red. Por otro lado, se encuentra la problemática inherente a la

Página 23


estructura de los documentos de HTML, debido a la propia naturaleza y flexibilidad del lenguaje. Acerca de esto último, existen investigaciones específicas que han demostrado la deficiencia que se tiene sobre este aspecto [20,21].

3.2. Diseño general de la propuesta de solución

Los dispositivos que interactúan diariamente con Internet, solicitan una enorme cantidad de recursos que se encuentran en la Web, pero ¿de qué manera se manipulan dichas solicitudes? ¿quién atiende y da respuesta a esas peticiones? Cuando un dispositivo cliente realiza una petición de un recurso de Web a través de su navegador, puede lanzar la petición directamente a Internet donde será atendida por el servidor de Web correspondiente. Pero también, puede hacerlo utilizando un servidor proxy, el cual será como su representante ante la red mundial.

Con el objetivo de dar una solución a la problemática planteada en el punto anterior, se ha desarrollado una metodología que involucra un mecanismo de transformación en línea, dirigido a servir recursos de Web (documentos de HTML) a dispositivos PDA, como los Pocket PCs.

La metodología de solución está basada en una arquitectura de tres capas, donde los servicios de transformación se encuentran implementados en un intermediario, el cual funciona como servidor proxy para los dispositivos de mano. En la figura 3.2. se muestra un esquema representativo a la arquitectura propuesta.

. . . . - . -

Fig. 3.2 Esquema de la arquitectura general de solucidn

Este trabajo forma parte de una arquitectura más general, es un componente de una plataforma middleware denominada Movi Ware’, cuya finalidad 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. La arquitectura general de MoviWare está representada en la figura 3.3.

Plataforma desarrollada en el Laboratorio de Sistemas Distribuidos del Depto. de Ciencias Computacionales, en I el Centro de Investigación y Desarrollo Tecnológico.

Página 24


Para nuestro caso en particular, se ha determinado la necesidad de integrar los servicios de transformación para los PDAs en un servidor intermediario. Así que ¿cuáles son las tareas que este intermediario tiene que llevar a cabo para cumplir con su trabajo? Son varias tareas las que se han de realizar, por lo que en las siguientes secciones se explica con más detalle cuál es la estrategia de solución.

Fig. 3.3. Aquiiedura general de la plataforma MoviWare.

3.3. Esquema general de operación del servidor Transformador

En la figura 3.4 se muestra el proceso general de operación seguido por el servidor Transformador, desde el momento en que recibe alguna solicitud de HTTP emitida por un dispositivo PDA como un Pocket PC.

Como se observa en la estructura general de operación, se encuentra integrado el mecanismo de transformación (resaltado con líneas punteadas) el cual se describirá posteriormente en este capítulo, y de igual forma, se ilustra la funcionalidad del sistema Cache soportado por el intermediario.

Página 25


................. ..............

..... .... ....... .... ........................ ....... ........ .... .... ., I '.. I ... ....

,,.. '< I

... %. pod

Capitulo 111 ANÁLISIS Y SOLUCI6N DEL PROBLEMA

recurso. Dicha información se organiza en encabezados, siendo el resto de la petición de HTTP el que se muestra enseguida:

Accept: * / * UA-OS: Windows CE (POCKET PC) - Version 3.0 UA-color: color16 UA-pixels: 240x320 UA-CPU: ARM SA1110 UA-Voice: FALSE UA-Language: JavaScript Accept-Encoding: gzip, deflate User-Agent: Moeilla/2.0 (compatible; MSIE 3.02; Windows CE; PPC; 240x320) Host: www.cenidet.edu.mx Proxy-Connection: Keep-Alive

Por tal razón, es posible determinar el tipo de dispositivo que está atendiendo el intermediario. El encabezado que contiene los datos de interés para llevar a cabo la identificación del cliente es User-Agent: valor. Como se muestra anteriormente resaltado en negritas, se tiene información acerca de la plataforma sobre la cual opera el dispositivo cliente; para este caso, se trata de un Pocket PC con Windows CE, equipado con un navegador Pocket Internet Explorer, el cual es equivalente a Microsoft Internet Explorer en su versión 3.02.

Una vez que se ha identificado el tipo de dispositivo cliente, se procede a analizar la petición para darle un seguimiento especial, diferente al que se le otorgm'a a un cliente convencional. Así que, se toma la primera línea (GET http://www.cenidet.edu.mx/ HTTP/I. 1) para obtener específicamente el valor correspondiente al contenido de Web solicitado. Una vez que se tiene este dato, se procede a hacer uso del servicio Cache integrado en el servidor Transformador. Por lo que enseguida se explica cómo funciona dicho sistema.

33.2. Esquema de funcionamiento del sistema Cache

El sistema Cache almacena páginas de Web transformadas que han sido solicitadas y servidas a dispositivos Pocket PC. Debido a que en este punto ya se tiene localizado el recurso de Web solicitado, se realiza una búsqueda de éste dentro del registro que se tiene de todos aquellos objetos almacenados en disco. Dicho registro contiene información referente acerca de cada una de las peticiones que han sido procesadas con éxito, por lo que, el recurso solicitado en cada una de éstas, fue almacenado en la Cache.

La estructura en la cual se auxilia el sistema Cache para llevar el control de sus elementos, Corresponde a un documento de XML, ai cual se le ha denominado cucheXML. Como se aprecia, cada item de cucheXML.xm1 corresponde a una petición de "M'p emitida por un dispositivo Pocket PC, para la cual se guarda el identificador del recurso (), la ruta en donde se localizará fisicamente el documento () y la fecha en que se ha solicitado éste (). La figura 3.5. muestra la estructura del documento.

Página 27

http://www.cenidet.edu.mx


........................................... ................................................................................................................. ..................................................... ................................... .....................................

! i i i http:/lwww.cenidet.edu.mxl ! ~Rutai/selene/proyectos/pruebas/bajados/~.cen¡det.edu.mxlt-¡ndex.html~/RUta~ i S i ~

Fig. 3.5. EstNciura del documento cacheXML.xml

Entonces, cada vez que se almacena un objeto en la Cache, se registra su entrada en esta estructura, por lo tanto, se van agregando nodos con su respectiva información, equivalente a la mostrada en la figura anterior.

De esta manera, se lleva a cabo una búsqueda del recurso incluido en la petición entre esos elementos, comparando el valor del nodo ; si coincide con alguno de ellos, se procede a verificar si el documento existe fisicamente en disco, y si es así, se recupera la página de HTML almacenada para enviarla como respuesta al cliente. De lo contrario, si el URL se encuentra registrado, pero no se localiza el recurso en disco o no se encontró ningún registro, se envía una respuesta negativa y el flujo de operación del sistema continúa, para lo cual, se reenvía la petición de HTTP al proxy Squid el cual lanzará la solicitud a la Web. Posteriormente, el servidor Transformador espera por una respuesta. En el momento en que logra recuperar el contenido de Web, enseguida solicita la ejecución del proceso de transformación.

3.33. Mecanismo de transformación de contenidos de Web

El diseño general de la estrategia para la transformación de páginas de Web, involucra una serie de fases, mediante las cuales se aplica una especie de preprocesamiento y reorganización al documento original. Para entender mejor esto, se pudo observar la figura 3.6, en la cual se muestra un esquema representativo del proceso que se sigue durante la etapa de transformación para obtener un nuevo documento de HTML.

Fig. 3.6. Esquema general del mecanismo de transfomadón

Página 28

Capltulo 111 ANÁLISIS Y SOLUCIÓN DEL PROBLEMA

EI mecanismo que se sigue para la transformación de los documentos, incluye como primer paso una fase que se denomina, Conversión de XHTML. En este punto se analiza la estnictura de la página de Web y se aplican las reglas de sintaxis del lenguaje XML, con el único fin de obtener un documento de HTML bien formado. Por lo cual, se utiliza un depurador de código en HTML denominado JTidy', el cual toma como entrada el contenido original, y como resultado, se obtiene dicho contenido con una estructura más clara y definida, que caracteriza a un documento de XHTML, lo cual significa que el contenido de Web sigue estando escrito en el lenguaje HTML, pero siguiendo las reglas de XML.

El código que se presenta en la figura 3.7 muestra algunos de los resultados de este proceso, ya que las etiquetas tales como 8 r > , ,

, etc. experimentan cierta transformación durante dicha fase. Esto se debe a que al escribir código en HTML no es necesario una etiqueta de cierre para éstas; en cambio el lenguaje XHTML no permite etiquetas como las anteriores. De este modo toda etiqueta
que se localice en el archivo HTML se cambia por 8 r b, así como

se convierte a

, etc.

Fig. 3.7. Transfomauón de la fase Convertidor de XHTML

UM vez que se ha logrado el paso anterior, el proceso continúa con la fase número dos, Analizador de HTML. En donde se utiliza un analizador de código en HTML, y se implementa una estrategia para obtener un documento de XML, con la finalidad de estandarizar el contenido para hacer uso de una tecnología que permita rediseñar el documento que se está tratando. De esta forma, ya que se tiene el ddigo de HTML en memoria, se establece una rutina para leer su contenido, explorando cada uno de sus elementos, y ai mismo tiempo se va creando un documento de XML, con los elementos que lo conforman. Por tal motivo, ahora el documento debe incluir la cabecera de un archivo de XML como lo muestra la figura 3.8.

JTidy. Herramienta que permite comprobar la sintaxis de un documento HTML.

Página 29


....... / .......................................................

Capitulo 111 ANALISIS Y SOLUCIÓN DEL PROBLEMA

En primer lugar, el objetivo que se persigue en esta etapa final, es darle un formato a la información que se tiene en una estructura de un documento de XML. Así que, la solución planteada incluye un Generador de Hoja de Estilo. ¿Qué significa esto? Como ya se ha mencionado, una vez que los datos se tienen en formato XML, se aplicará un formato de presentación a los mismos, ya que por sí solos no poseen el estilo de una página de Web, sino que son puramente texto. Por esta razón, se tiene que crear la cara con la que un navegador visualiza dicha información.

Es por eso, que se realiza un análisis del contenido que se tiene como resultado de las fases anteriores, mediante una actividad que se llama Extractor de Elementos, donde se extraen valores que ayudan a determinar la composición del nuevo documento de HTML. Como se observa en la figura 3.9, existe una retroalimentación en la parte de la generación de la hoja de estilo y la extracción de los elementos analizados.

Durante la creación del formato que se va a dar a la información contenida en el documento de XML, se loya obtener un esquema que permite reorganizar los elementos originales, para lo cual se han agrupado por tipo de elemento. De tal forma que aparecerá primero el texto de la página de Web, seguido de un grupo de imágenes en miniatura, y d find se muestran los enlaces que se hayan obtenido durante el análisis. En la figura 3.10 se observa la hoja de estilo generada durante esta etapa.

qxml version="l .O" endmg="iso-8859-1" ?> . . .. . ,.. Qoay .bgcolor="#FFFFFF"> . . a b l e align="eenter" bordei-"Z"> . ,

Transformador de Contenido Web para PDAs

. .

Capitulo 111 ANALISIS Y SOLUCIÓN DEL PROBLEMA

una página de HTML, pero ahora con características que permiten visualizarla de una manera más sencilla en un navegador de un dispositivo con una pantalla de dimensiones reducidas.

3.3.4. Gestión de la respuesta de HTTP al cliente

Una vez que ya se tiene el resultado del mecanismo de transformación, ¿de qué manera se da respuesta a la petición del cliente que solicitó dicho recurso? Primeramente, se tiene que aprovechar el sistema Cache proporcionado. Para esto es conveniente guardar la página de Web transformada, así que se gestiona el almacenamiento en disco, y posteriormente se procede a construir una respuesta de HTTP, por lo tanto, se construye una cabecera con el formato que se muestra a continuación; por ejemplo:

HTTP 1.1 200 OK MIME-version: 1.0 Content-type: texüplain Content-length : 38

617-555-6789

En la respuesta se observa una primera línea, la cual indica que se esta trabajando con el protocolo HTTP en su versión 1.1, seguido de un código de estado (200 OK) que indica que la petición se llevó a cabo con éxito, para otros casos existe una diversidad de códigos establecidos dentro de la especificación del protocolo H l T . Enseguida, se tienen otros encabezados con información referente al tipo y al tamaño en bytes del documento. Finalmente se envía el cuerpo del mensaje, es decir, el contenido de la página de Web a través del canal de datos que se estableció al momento de conseguirse la conexión entre el cliente y el servidor Transformador.

P e n a 32

CapiNlo IV ARQUITECTURA DEL SERVIDOR TRANSFORMADOR

Arquitectura del Servidor Transformador.

En este capítulo se analizará la arquitectura del servidor Transformador con más detalle, abordando la composición de clases que lo constituyen, y describiendo la funcionalidad de cada una de ellas dentro del intermediario.

PBgina 33

Capítulo IV ARQUITECTURA DEL SERVIDOR TRANSFORMADOR

4.1 Diagrama de secuencias del proceso operativo del sistema

Utilizando el lenguaje de modelado UML' se presenta el diagrama de secuencias, en ía figura 4.1 ., el cual muestra la operación general del prototipo consiruido en este trabajo.

Abre >

[Si no está en la Cache] Soliciiagágina-a la-Web

[Si es PDA] ransfonna pI I á ina + h n s f y d o /

Página-transfomada

Capítulo IV ARQUlTECTURA DEL SERVIDOR TRANSFORMADOR

Se utiliza para cargar los valores de configuración correspondientes a las nitas del sistema de archivos, información sobre el período en Cache de los recursos, direcciones IP y número de puerto del servidor proxy Squid y del servidor Transformador.

Métodos:

unuíizuo. Se utiliza para analizar y cargar los valores que se encuentran en el archivo de configuración en un objeto correspondiente a una tabla hash. getConfigurucion0. Regresa la estructura anterior una vez que es solicitada.

Clase: hiloserver.

Se encarga de gestionar cada una de las solicitudes de HTTP en un hilo de ejecución, obteniendo el resultado final que envía al cliente.

Métodos:

run@ Su función es gestionar la petición, desde el momento en que se recibe hasta que se otorga un resultado final.

Clase: manipulacaehe.

Su función es manipular el sistema Cache, verificando la existencia de recursos, almacenando nuevas peticiones, actualizando la información referente a los accesos recientes, y también se encarga de la depuración de los objetos almacenados fisicamente.

Métodos:

ugregui'eticion0. Adiciona un nuevo nodo Petición a la estructura correspondiente, en esta caso, a la estructura jerárquica de nodos que se tiene en memoria. ulmucenuCuche0. Guarda fisicamente en disco la información referente a la petición actual. borrdrchivoso. Elimina fisicamente del medio de almacenamiento los objetos que le sean señalados. 6uscuRecursoEnCacheO: Realiza una exploración, buscando un elemento en la Cache que coincida con el dato que se tiene del recurso (url) solicitado por el cliente. creaCucheXML0. Crea la estructura (cacheXML) la primera vez que se ejecuta el servidor, o cuando ésta haya sido eliminada mientras el intermediario esté funcionando. depururCuche0. Se encarga de eliminar los recursos que han sobrepasado la duración que se tiene establecida comoperiodo en Cache. leeCacheXML0. Su función es leer el documento de XML y cargarlo en memoria para su posterior manipulación. verzjhFiZe0. Como su nombre lo indica, verifica si el recurso que se tiene registrado en Cache, existe realmente en disco.

Página 36

Capítulo 1V ARQUITECTURA DEL SERVIDOR TRANSFORMADOR

Clase: identificadorDispositivo.

En esta clase se lleva a cabo el análisis del contenido de la solicitud de HTTP, donde se localiza el encabezado User-Agent, que informa acerca de la plataforma que está realizando la petición al intermediario.

Métodos:

anulizuPeticion0. Realiza un análisis sobre la estructura de la solicitud de HTTP recibida, examinando la información contenida en sus encabezados. obfenerPeticion0. Regresa el valor de la petición analizada en una estructura StringBuffer.

Clase: bajaArchivoHTML.

Como su nombre lo indica, esta clase se encarga de reenviar la petición al proxy Squid y esperar una respuesta, para posteriormente enviar el archivo recuperado a la clase Transformador.

Métodos:

downloudFile0. Se encarga de recuperar el documento solicitado por el cliente, para posteriormente pasarlo al mecanismo de transformación, y esperar un resultado.

Clase: transformador.

La función de la clase transformador es controlar el proceso de la generación de un nuevo documento, a través de una serie de etapas que involucran la participación de otras clases, pero siendo ésta la principal de dicho proceso.

Métodos:

. trunsformaArchivo0. Su función es controlar el proceso que involucra la transformación del documento original, a través de varias etapas.

4.2.1. Estnictura de clases del mecanismo de transformación

El mecanismo de transformación de contenidos de Web integrado en el intermediario e implementado en la clase trunsformudor, se auxilia con un conjunto de clases para realizar su trabajo. Dichas clases se presentan en la figura 4.4 y se describen posteriormente.

Página 37

Capítulo IV ARQUITECTURA DEL SERVIDOR TRANSFORMADOR

u ,'l,.l 4 1..1

\

/

,/'

\

\ \ \

i,

i

Fig. 4.4. Estructura de clases del mecanismo de transfomacibn

Clase: convertidorXHTML.

Esta clase se encarga de dar una mejor estructura al documento de HTML original, aplicando las reglas de marcado del lenguaje XML.

Métodos:

procesuHTML0. Este método implementa un depurador de código denominado JTidy, para dar una reestructuración al contenido original.

Clase: analizadorHTML.

Una vez que se lleva a cabo la reestructuración anterior, la función de la clase analizadorHTML es leer dicho documento y pasarlo a memoria

Métodos:

umZizaCodigoXWML0. Carga en memoria el contenido originado en la clase anterior, utilizando la clase JDOM para manipularlo. printo. Recorre todos los elementos y va generando como salida un documento con estructura XML, aplicando las reglas de sintaxis establecidas por el lenguaje.

Página 38

Capitulo 1V ARQUITECTURA DEL SERVIDOR TRANSFORMADOR

Clase: analizadorXML.

El analizadorXML se utiliza para manipular el contenido en una estructura de árbol y explorar su contenido.

Métodos:

anulizuCodigoXML0. Invoca un análisis sobre el documento obtenido en lenguaje XML. pursero. Realiza el análisis y obtiene el documento raíz del contenido.

Clase: reformateador.

Su función es reorganizar los elementos contenidos en el documento original, proporcionando una agnipación de dichos elementos con un nuevo formato.

Métodos:

generurHojuEstiio0. Genera la plantilla que dará formato a la información que se tiene en el archivo de XML que contiene los datos originales, produciendo un archivo de XSL. íruns$ormaXML-~MLO. Implementa la clase íransformer para procesar los datos en XML y XSL, dando de nuevo como resultado, un documento de HTML.

Clase: extractorElementos.

Se encarga de realizar un análisis de los elementos principales del documento que localiza en memoria en forma de nodos, para determinar el contenido del nuevo documento.

Métodos:

imprirneHijosBo&O. Se utiliza para determinar el

CENTRO NACIONAL DE INVESTIGACIÓN Y DESARROLLO · Transformador de Contenidos Web para Asistentes...

Documents

Transcript of CENTRO NACIONAL DE INVESTIGACIÓN Y DESARROLLO · Transformador de Contenidos Web para Asistentes...