Sistema integral de búsqueda en Internet basado en servicios Web

Alfonso Capella D’alton, Juan Carlos Monllor Pérez y Francisco Maciá Pérez

La Word Wide Web se ha constituido en una fuente de información de primera magnitud, abarcando un amplio abanico de contenidos sobre múltiples temáticas y en diferentes formatos. No obstante, debido precisamente a la inmensa cantidad de información que alberga y a su naturaleza multimedia y entrelazada, con frecuencia es difícil encontrar exactamente la información que buscamos. Para resolver este problema, surgen los buscadores en Internet, como mecanismos que nos permiten obtener los contenidos que se ajustan a nuestros criterios de búsqueda. En este trabajo se realiza un análisis de los diferentes enfoques y tecnologías que facilitan la inclusión de buscadores en nuestros sitios Web y se propone una implementación basada en servicios Web; en concreto, en el motor de búsqueda que proporciona el conocido buscador de Internet, Google. Finalmente, se presenta como caso de uso la implementación realizada en el nuevo sitio Web del Departamento de Tecnología Informática y Computación de la Universidad de Alicante.

1 Introducción

La Word Wide Web (WWW) se ha constituido en una fuente de información de primera magnitud, abarcando un amplio abanico de contenidos sobre múltiples temáticas y en diferentes formatos. No obstante, debido precisamente a la inmensa cantidad de información que alberga, a lo heterogéneo de su contenido, y a su dispersión en múltiples servidores y sitios Web —relacionados mediante una difusa y

no siempre coherente jerarquía de enlaces—, con frecuencia es difícil encontrar exactamente la información que buscamos. Para resolver este problema, surgen los buscadores genéricos en Internet, como mecanismos que nos permiten realizar consultas – de forma análoga a los sistemas de bases de datos —y obtener un conjunto de direcciones URL cuyos contenidos se ajustan a nuestros criterios de búsqueda.

Para multitud de organizaciones que se incorporan a Internet, e introducen su información en la WWW, disponer de un servicio de búsqueda es una ventaja que genera gran valor añadido, pues el acceso rápido y en línea a la información relevante se perfila como la característica crucial para el éxito de cualquier sitio Web.

No obstante, el dotarse de un sistema de búsqueda propio conlleva un coste en infraestructuras (servidores, plataformas software y middleware) y personal para su desarrollo, implantación y mantenimiento; asimismo, su ámbito de búsqueda estaría en principio mucho más restringido que el de los buscadores genéricos, abarcando tan sólo la Web corporativa de la organización.

Este escenario está cambiando en la actualidad, debido a la evolución de una nueva tecnología: los servicios Web, un estándar para la integración de aplicaciones Web mediante el uso de lenguajes y protocolos abiertos como XML y TCP/IP. Esta tecnología hace posible que el servicio de búsqueda de una organización sea proporcionado por una empresa externa, de forma totalmente transparente a los usuarios, que reciben los resultados a través de la aplicación Web corporativa.

En este capítulo expondremos las diversas opciones tecnológicas que podemos utilizar a la hora de proporcionar el servicio de búsqueda.

Finalmente, abordaremos un caso práctico: el servicio de búsquedas implantado en el nuevo portal del Departamento de Tecnología Informática y Computación de la Universidad de Alicante, que utiliza la avanzada tecnología del buscador Google gracias al sistema de servicios Web ofrecido por éste.

2 El problema de la búsqueda de información en Internet

La red mundial de servidores HTTP conocida como World Wide Web (WWW) alberga una enorme cantidad de información, plasmada en documentos de distintos formatos. Entre estos formatos, destaca el lenguaje de marcación de hiper-texto (HTML), el cuál permite representar contenidos textuales en múltiples idiomas, incluir elementos multimedia tales como imágenes, audio o video así como establecer referencias (hiper-enlaces) a otros documentos presentes en la Web.

Fig. 1. Elementos básicos que constituyen una URL.

Distintos estudios han tratado de medir el tamaño de la WWW, y aunque con ligeras variaciones, la mayoría estiman dicho tamaño en más de mil millones de páginas [1]. Teniendo en cuenta que el tamaño medio de cada página HTML es de aproximadamente 10 kilobytes, ello supone un volumen de 10 terabytes sólo en código HTML. Y las previsiones de crecimiento son espectaculares: el tamaño de la Web se ha duplica en menos de dos años, y parece que este ritmo continuará en los próximos años [2].

¿Cómo se organiza tal cantidad de información en la WWW? Todo documento presente en la misma es accesible a través de su URL (localizador uniforme de recursos), la cuál está formada básicamente por el protocolo a utilizar (normalmente HTTP), la dirección DNS (nombre de dominio) o IP del servidor que lo aloja (junto al número de puerto) y la ruta de directorios donde reside más el nombre del propio documento (fig. 1).

Prot

ocol

o

Nom

bre

DNS

del

serv

idor

(o d

irecc

ión

IP)

Puer

to d

el s

ervi

dor

Ruta

de

dire

ctor

ios

Nom

bre

del

docu

men

tohttp :// www.dtic.ua.es : 80 /grupoM/ index.htm

Así, los nombres DNS suelen representar organizaciones y departamentos, las rutas de directorios grupos y secciones y por último, el nombre del propio documento suele referenciar su contenido (por ejemplo, lista-aprobados.html). No obstante, la nomenclatura y estructura concretas no se encuentran estandarizadas, sino que cada sitio Web adopta sus propias convenciones para organizar los documentos que ofrece.

Esta organización es lógica desde el punto de vista de la arquitectura de sistemas informáticos cliente/servidor, no obstante en algunos casos resulta inadecuada e ineficiente, particularmente desde el punto de vista semántico y de categorías temáticas.

Por el contrario, otros esquemas organizativos, como el índice CDU aplicado en biblioteconomía, han sido concebidos para permitir una catalogación pormenorizada de cada documento, siguiendo una elaborada jerarquía de áreas temáticas en las que se encuadra dicho documento. Estos esquemas, aunque no reflejan la arquitectura cliente/servidor, resultan mucho más adecuados para la búsqueda de información, ya que el usuario sólo necesita saber el área temática donde se encuadra el documento que busca.

En cambio, en la organización de la WWW, el usuario debe conocer detalles como el nombre DNS del servidor que aloja el documento, y la ruta de directorios que lleva al mismo; detalles que pertenecen a la infraestructura tecnológica de Internet y que por tanto deberían ser transparentes para el usuario.

Otro obstáculo a la hora de buscar es la volatilidad de la Web: los documentos son modificados, trasladados a otras ubicaciones o eliminados con gran frecuencia [3,4,5], lo cuál hace aún más difícil encontrarlos. Por último, aunque la mayoría de documentos se encuentran en formato HTML, cada vez es mayor la presencia de otros formatos (PDF, Word) y de contenido multimedia, lo que requiere de un esfuerzo adicional a la hora de extraer la información.

Este escenario plantea el conocido problema de la búsqueda de información en Internet: si el usuario desconoce a priori la URL del

documento que contiene dicha información, ¿cómo podrá acceder a ella? La respuesta está en los motores de búsqueda, sistemas informáticos capaces de resolver la consulta del usuario presentándole una lista de URLs que contienen información relacionada con el objeto de la consulta.

Estas consultas suelen basarse en la búsqueda de palabras clave unida a un conjunto de operadores lógicos (ej: “tabla Y periódica”), de dominio (ej: “EN_EL_SITIO dtic.ua.es”) y categorías (ej: “CATEGORÍA turismo”). Asimismo, el resultado de la consulta, es decir, la lista de URLs, suele ordenarse en función del grado de proximidad o emparejamiento (matching) del contenido de cada URL con los términos de la búsqueda, colocando en primer lugar los más próximos (este ordenamiento se conoce como ranking [1]). Por último, junto a cada URL se incluye de forma habitual un pequeño extracto, lo más significativo posible, del documento referenciado por dicha URL.

3 Las tecnologías de búsqueda en Internet

En función del ámbito y la forma de llevar a cabo las búsquedas en Internet, podemos clasificar los motores de búsqueda en las siguientes categorías:

• Buscadores genéricos

• Buscadores ad hoc (a medida)

• Buscadores basados en módulos de servidor Web

• Buscadores basados en servicio de red

• Buscadores basados en dispositivo de red (network appliance)

Cada una de estas categorías se ajusta mejor a un determinado tipo de búsqueda y entorno de implantación: ámbito local/general, tecnología Web empleada, coste de desarrollo/mantenimiento… características que habremos de valorar a la hora de decidir qué motor de búsqueda adoptar para nuestro sitio Web.

3.1 Buscadores genéricos

Los motores genéricos permiten realizar búsquedas que abarcan todos los dominios (DNS) y por tanto, en la práctica, todos los sitios Web existentes en Internet.

Debido a que, como mencionamos en la introducción, cada sitio Web posee sus propias normas para organizar los documentos que contiene, un motor genérico debe ser capaz de analizar cada sitio Web por separado, inferir su estructura, extraer la información relevante de sus documentos y clasificar los mismos de acuerdo con sus propios criterios de búsqueda (áreas temáticas, palabras clave, relevancia...)

Para ello, el motor de búsqueda debe dotarse de una infraestructura tecnológica como la observada en la figura 2. La pieza clave de dicha arquitectura consiste en los crawlers o robots de exploración, los cuáles llevan a cabo una navegación continua por la Web: recorren los hiper-enlaces presentes en los documentos Web, obteniendo los documentos referenciados por estos últimos y así recursivamente. Estos robots de exploración son coordinados desde el módulo de control de crawlers, el cuál les indica qué URLs deben seguir. Si el dominio de búsqueda es la WWW, entonces las URLs de partida serán los directorios raíz de cada servidor WWW presente en Internet (los cuáles pueden ser localizados gracias a los registros DNS). El módulo de control distribuirá dichas URLs entre los robots exploradores.

A medida que los crawlers obtienen documentos, los van depositando en un almacén conocido como repositorio de páginas. Desde dicho almacén, los documentos son recuperados por el módulo de indexado para elaborar los correspondientes índices. Existen diversos tipos de indexación: textual (basada en palabras clave), estructurales (que reflejan los enlaces entre documentos), de utilidad (indexan en función de características como el idioma, el dominio DNS, el autor, la categoría…).

Estos índices son utilizados posteriormente por el motor de búsqueda para resolver las consultas del usuario, de manera que a partir de un conjunto de palabras clave relacionadas con operadores de búsqueda (booleanos, de dominio, categoría, etc.) se obtiene el conjunto de URLs que encajan con dichos criterios.

Fig. 2. Arquitectura de un motor de búsqueda genérico [1].

Finalmente, este conjunto es ordenado por el módulo de ranking en función de los índices de utilidad, por orden decreciente de proximidad a los criterios de búsqueda.

Los índices de utilidad proporcionan una valiosa información para establecer el orden; por ejemplo, el número de documentos de la misma temática (o con similares palabras clave) que referencian una determinada URL constituye una buena estimación de la importancia de dicha URL (ej: documentos sobre sistemas operativos que referencian la página de Andrew S. Tanenbaum).

Usuario Cliente

Motor debúsqueda Ranking

Resultados

Repositoriode páginas

Crawlers

Internet

ServidoresHTTP

(World Wide Web)

HTTP GET

HTTP GET

HTTP GET Módulo deindexado Módulo de

análisis derecopilaciones

Texto Estructura UtilidadÍndices

Consultas

Retroalimentación texto/estructura

Realimentació

n basada en uso del motor

Control decrawlers

Por último, una revisión de esta tecnología de búsqueda no estaría completa sin hablar de los costes. El coste en recursos tecnológicos (red, disco, memoria y CPUs) de un buscador genérico puede ser medido en base a tres factores:

• Ancho de banda consumido en la exploración Web (crawling)

• Coste espacial del almacenamiento de documentos (repositorio de páginas)

• Coste temporal de los procesos aplicados a documentos e índices

Estos tres factores dependen esencialmente del ámbito de búsqueda; si dicho ámbito es la WWW, entonces habremos de dimensionarlos en función del tamaño de la misma (1000 millones de páginas y 10 terabytes sólo en código HTML [1]), con la consiguiente escalada en recursos necesarios. Si el ámbito es local a un sitio Web, entonces los costes serán más fácilmente asumibles por la organización que lo gestiona, pues el tamaño del sitio Web suele ser proporcional al tamaño de la propia empresa.

En cuanto al coste de desarrollo y mantenimiento, éste vendrá dado fundamentalmente por la complejidad de los algoritmos de exploración, almacenamiento, indexado y resolución de consultas (el coste software). A ello habría que sumar el coste adicional de los conversores de formato, si deseamos que nuestro buscador sea capaz de encontrar información en documentos PDF, Word, etc. Además, es preciso tener en cuenta que la WWW es un entorno en continua transformación, por lo que probablemente será necesario modificar los algoritmos para adaptarlos a dichas transformaciones. No obstante, existen proyectos de código abierto [6,7,8] que podríamos utilizar para nuestro buscador (ya sea en su totalidad o aprovechando componentes), ahorrándonos su desarrollo y mantenimiento.

3.2 Buscadores ad hoc

Los buscadores ad hoc o propios son aquellos desarrollados a medida para un sitio Web concreto, ajustándose a las necesidades específicas de dicho sitio.

Aunque en ocasiones aplican ideas, principios y técnicas tomados de los buscadores genéricos, no lo hacen de manera sistemática. En su lugar, desarrollan algoritmos y heurísticas propias, válidas exclusivamente en el ámbito del sitio Web para el que son creados, lo cuál conlleva la pérdida de generalidad.

En compensación, y dado que normalmente se dispone de un gran conocimiento sobre los datos contenidos en el sitio, dicho conocimiento puede ser aplicado a la hora de diseñar el motor para aumentar el nivel de información de los algoritmos de búsqueda, mejorando así su rendimiento y calidad.

Este es el caso del motor de búsqueda empleado en el antiguo (1995-2005) sitio Web del Departamento de Tecnología Informática y Computación de la Universidad de Alicante (desarrollado por Francisco Maciá Pérez y Juan Antonio Gil Martínez-Abarca), en el cuál el algoritmo conocía perfectamente la importancia de las columnas en cada tabla de la base de datos, importancia que podía ponderar a la hora de valorar (ranking) los resultados de la búsqueda. Así, si buscáramos el término “Jerónimo”, el algoritmo encontraría coincidencias en la tabla de profesores (los datos del profesor Jerónimo Mora) así como en la tabla docencia de asignaturas (las asignaturas impartidas por dicho profesor); dependiendo del contexto de la búsqueda (personas o asignaturas), el algoritmo colocaría en primer lugar la entrada de profesor o las correspondientes a asignaturas impartidas.

La información más valiosa a la hora de diseñar los algoritmos a medida es con frecuencia el propio esquema del sistema de información, expresado a través de modelos como el entidad-relación extendido [9], el cuál nos proporciona un conocimiento cuya inferencia

a partir de la estructura y contenido del sitio Web sería extremadamente difícil cuando no imposible.

En cuanto a los costes de desarrollo y mantenimiento de un buscador propio, al igual que en el caso de los buscadores genéricos, dependen en gran medida de la complejidad de los algoritmos. Sin embargo, dado que los algoritmos son diseñados a medida del sitio Web, su complejidad estará en función del tamaño y la estructura del propio sitio Web; y como este último normalmente es proporcional a la dimensión de la empresa, se deduce que dichos costes serán asumibles para la organización, siempre que no se sobredimensione el sitio Web con respecto al tamaño de la empresa. Tal era el caso del buscador original para el sitio dtic.ua.es, mencionado anteriormente.

Por supuesto, el coste de mantenimiento dependerá también de la frecuencia y magnitud de los cambios introducidos en la Web, los cuáles a su vez vendrán dados por la dinámica de la propia empresa. En sistemas de información donde las pautas están ya suficientemente acotadas, donde no son previsibles grandes cambios, el coste de mantenimiento será mínimo —como en el caso de los sistemas financieros.

Por último, la portabilidad o capacidad de migración a otras plataformas tecnológicas de los motores de búsqueda ad hoc suele estar limitada por su estrecha vinculación a las tecnologías empleadas en el sitio Web. Es decir, los algoritmos diseñados a medida del sistema de información propio suelen implementarse también a medida de las tecnologías propias del sitio (utilizando los mismos lenguajes de programación, bibliotecas de funciones, etc.). Esta limitación se diluye a medida que empleamos lenguajes y bibliotecas más generales y portables (como Java, JDBC, JNDI, …).

3.3 Buscadores basados en módulos de servidor Web

Tales buscadores consisten en módulos de componentes que se acoplan al servidor HTTP del sitio Web donde proporcionarán el servicio de búsqueda. A partir de dicho instante, el buscador comienza

el análisis del sitio Web a fin de crear una base de datos (similar al recopilatorio de páginas de la fig. 2) sobre los contenidos del sitio (digging o extracción de información) [6]. A continuación, tiene lugar la creación de otra base de datos especializada, optimizada para las búsquedas, similar a la base de datos de índices de los buscadores genéricos; este proceso se conoce como merging (combinación). Ambas bases de datos se actualizarán periódicamente para recoger los cambios en el contenido y la estructura del sitio Web.

A su vez, otro componente del módulo proporciona al usuario el interfaz Web a través del cuál realizar sus consultas. Dicho componente recoge los criterios de búsqueda especificados por el usuario y los confronta con la base de datos combinada (merged), obteniendo los correspondientes emparejamientos (matching) y a través de ellos el resultado de la búsqueda (lista de URLs relacionadas).

Por otra parte, el coste de desarrollo y mantenimiento de este tipo de buscadores es cercano a cero, pues tan sólo es necesario proporcionarles la configuración básica e incorporarlos al servidor Web para el que fueron creados (al estilo plug & play).

En ocasiones, estos buscadores no son desarrollados para un servidor específico, sino que se basan en una tecnología de interfaz (como CGI [10]), permitiendo su integración con cualquier servidor Web que incorpore dicha tecnología.

Por último, en cuanto a las posibilidades de migración, los buscadores basados en módulo para servidor Web son portables entre distintas plataformas, siempre y cuando mantengamos el mismo servidor Web (o tecnología de interfaz) para el que fueron diseñados.

3.4 Buscadores basados en servicio de red

En este tipo de buscadores, el motor de búsqueda es proporcionado por un proveedor de servicio, a través de un interfaz estandarizado basado en servicio de red - como los servicios Web [12]. Así, nuestra

aplicación Web de búsqueda se limitará a recoger la consulta del usuario, encapsularla en una petición con el formato especificado por el interfaz del servicio de red y enviarla al proveedor del servicio. Adicionalmente, un servicio de descubrimiento (como UDDI [12]) puede hacer de intermediario, proporcionándole a nuestra aplicación la dirección del proveedor y la especificación del interfaz.

Una vez resuelta la consulta por el motor de búsqueda externo, el proveedor del servicio responderá a nuestra aplicación con el resultado de la búsqueda, mediante una respuesta encapsulada conforme al interfaz pactado. A partir de este instante, nuestra aplicación dispone del resultado en un formato de datos portable que podrá procesar, filtrar, transformar en formato visual, etc. Finalmente, la aplicación de búsqueda de nuestro sitio Web enviará al usuario el resultado procesado, filtrado y con formato visual.

Una consecuencia importante de este sistema es que permite integrar las capacidades de búsqueda externas a nuestra aplicación Web corporativa, de forma totalmente transparente para el usuario. En efecto, el usuario final desconoce los detalles acerca de quién lleva a cabo la búsqueda o cómo se comunica la aplicación Web con el motor de búsqueda externo; para él, es como si fuera la propia Web corporativa la que realizara todo el proceso. De esta manera, la Web corporativa gana en coherencia en cuanto a su interfaz de usuario, que sigue siendo exactamente el mismo a pesar de que un servicio, en este caso el de búsqueda, es prestado por otra organización.

Otra consecuencia importante de este sistema es la posibilidad de incorporar servicios de búsqueda avanzados, incluso en todo el dominio de Internet, a sitios Web de organizaciones que no pueden asumir el coste de la tecnología necesaria para prestar tales servicios, pero en cambio sí pueden contratarlos a un proveedor externo (como Google).

A la hora de implantar un buscador de este tipo, es preciso tener en cuenta que sólo la parte pública de nuestro sitio Web será accesible por el proveedor del servicio de búsqueda, por tanto las búsquedas

estarán restringidas a dicha parte pública, no siendo posible buscar información en la intranet corporativa.

Por otro lado, los costes de desarrollo y mantenimiento de este tipo de buscadores son mínimos, centrándose en la integración del servicio externo dentro de la propia aplicación Web. La facilidad con que lograremos dicha integración dependerá del interfaz del servicio, del soporte disponible para el mismo en el propio servidor Web (o la plataforma sobre la cuál está basado) y de la disponibilidad de bibliotecas de clases o funciones que encapsulen los detalles del interfaz.

Por último, es necesario añadir el coste económico del servicio de búsqueda externo. Así, el proveedor del servicio fijará una tarifa determinada, que normalmente estará en función del número de consultas a satisfacer.

Como ejemplo de servicio de red de búsquedas, está el servicio Web ofrecido por Google [11], el cuál permite enviar las consultas encapsuladas a través del protocolo SOAP [12] y recibir los resultados del mismo modo.

3.5 Buscadores basados en dispositivo de red (network appliance)

En ellos, el motor de búsqueda es proporcionado por un conjunto altamente integrado de hardware y software, encapsulado en un dispositivo de red (network appliance), el cuál incorpora la tecnología de búsqueda genérica (crawlers, conversores de formato, bases de datos de índices, ranking, …)

Tales dispositivos se caracterizan por un funcionamiento similar a los electrodomésticos, del tipo conectar y listo (plug & play) y con unas necesidades mínimas de administración (zero administration). Es decir, para poner en marcha el sistema de búsqueda resulta suficiente con alimentar el dispositivo y conectarlo a la red; a partir de dicho instante, el dispositivo se autoconfigurará y comenzará a ofrecer el

servicio de búsqueda. En algunos casos, el dispositivo puede requerir una ligera configuración inicial para ajustar ciertos parámetros, como el dominio de búsqueda.

Adicionalmente, los dispositivos de red – que se conectan a la red privada del sitio Web – pueden acceder a la parte privada del mismo, permitiendo búsquedas en la intranet corporativa. El propio dispositivo gestiona la seguridad de las búsquedas, garantizando que cada usuario puede acceder únicamente a la información para la cuál está autorizado.

Los buscadores basados en dispositivo de red presentan un coste de desarrollo cero desde el punto de vista de la empresa que lo adquiere, y un coste de implantación y mantenimiento mínimos gracias a las capacidades de autoconfiguración y administración de los dispositivos de red.

Como ejemplo de este tipo de buscadores está el search appliance [13] de Google, el cuál incorpora la tecnología de búsqueda del motor de Google encapsulada en un dispositivo de red, permitiendo buscar entre 15 millones de documentos con más de 220 formatos de archivo y garantizando la seguridad en el acceso a tales documentos (se mantienen los privilegios de acceso del usuario que realiza la búsqueda).

Fig. 3. Dispositivo de red search appliance de Google.

4 Servicios Web

Los servicios Web [12] constituyen una tecnología estándar para la integración de aplicaciones que se comunican entre sí a través de redes de computadores. Esta tecnología utiliza lenguajes y protocolos

abiertos como XML, SOAP, WSDL, UDDI y TCP/IP, y permite el intercambio de información entre las aplicaciones de forma transparente a las mismas, es decir, sin que cada aplicación deba conocer los detalles de implementación de su contraparte. Gracias al uso de servicios Web, las aplicaciones pueden compartir lógica de negocio y datos por medio de un interfaz programático a través de la red. Cabe destacar que esta tecnología representa uno de los estándares más importantes para la provisión y consumo de servicios de red, siendo respaldada por el W3C (World Wide Web Consortium).

Fig. 4. Secuencia de interacciones requeridas para acceder a un servicio Web.

Los diversos lenguajes y protocolos que forman parte de los servicios Web se utilizan con los siguientes fines:

• XML es el lenguaje para el intercambio de datos transparente (formato portable)

• SOAP es el protocolo que permite al cliente del servicio invocar métodos de objetos remotos proporcionados por el proveedor del servicio.

• WSDL es el lenguaje de descripción de los servicios Web, que sirve para especificar el interfaz que deben usar las aplicaciones para comunicarse con cada servicio.

12

3

4

1 Publicación1 Publicación

2 Búsqueda2 Búsqueda

3 Descubrimiento3 Descubrimiento

4 Consumo4 Consumo

Registro UDDIService Broker

Registro UDDIService Broker

Servicio Web Service ProviderServicio Web Service Provider

Aplicación Web Service RequesterAplicación Web Service Requester

Hoja WSDL

Solicitud UDDI

Hoja WSDL

Mensajes SOAP

• UDDI es el protocolo de descubrimiento utilizado por los clientes del servicio Web para obtener la dirección del proveedor del servicio, gracias a la intervención de un tercer actor: el registro UDDI (que actúa como intermediario).

• TCP/IP es el protocolo de comunicaciones utilizado por los protocolos anteriores para la transmisión de datos a través de la red.

5 Servicio Web del buscador Google

Google ofrece el uso de su motor de búsqueda a través de servicio Web [11].

Como mencionamos anteriormente, la tecnología de los servicios Web es fácilmente integrable en aplicaciones Web, lo que convierte a este servicio en candidato idóneo para implantar un sistema de búsquedas en cualquier sitio Web.

El primer paso para acceder a este servicio consiste en registrarse en el sitio de Google [11], donde obtendremos una clave de licencia que nos autoriza a realizar hasta mil consultas diarias a través de su servicio Web. Posteriormente, desde el mismo sitio, descargaremos un paquete software que contiene

• La descripción del servicio Web (WSDL)

• El Google Java API. Se trata de una biblioteca de clases Java que sirven de envoltorio (wrapper) al servicio Web, encapsulando los detalles de los protocolos SOAP y UDDI y del lenguaje WSDL. Con esta biblioteca, es posible programar el acceso al servicio de Google sin conocer ninguno de estos protocolos o lenguajes.

• La documentación del Google Java API • Ejemplos de uso del servicio a través del Java API, de aplicaciones

.NET y mediante el uso directo del protocolo SOAP.

El Java API nos provee de un conjunto de clases y métodos muy útiles para acceder al motor de Google, permitiendo realizar búsquedas avanzadas (consultas con operadores), restringir el dominio de búsqueda, realizar filtrados (por ejemplo para aislar el contenido que pueda herir la sensibilidad del usuario) e incluso obtener las sugerencias ortográficas de Google (“usted quiso decir…”).

A continuación ofrecemos un pequeño ejemplo de código fuente Java que lleva a cabo una búsqueda, utilizando el Java API de Google: // CREAR OBJETO PARA BÚSQUEDA EN GOOGLE GoogleSearch googleSearch = new GoogleSearch(); // ESPECIFICAR PARÁMETROS DE BÚSQUEDA googleSearch.setKey(claveLicencia); googleSearch.setQueryString(cadenaBuscar); googleSearch.setStartResult(1); googleSearch.setMaxResults(10); // LLAMAR AL SERVICIO WEB GOOGLE // REALIZAR LA BÚSQUEDA Y RECOGER SU // RESULTADO GoogleSearchResult googleResults = googleSearch.doSearch(); // OBTENER ELEMENTOS RESULTANTES DE LA BÚSQUEDA GoogleSearchResultElement[] googleElems = googleResults.getResultElements();

Por supuesto, el Java API puede utilizarse tanto desde una aplicación Web como desde una aplicación cliente (de consola, gráfica e incluso applets siempre y cuando posean permisos para acceder al Java API y enviar los mensajes SOAP).

6 Propuesta para el buscador del nuevo sitio Web D:TIC

Durante el mes de abril de 2005, el equipo técnico del Departamento de Tecnología Informática y Computación de la Universidad de Alicante, en colaboración con el grupo de redes del mismo departamento, estaba ultimando la nueva Web corporativa. Por aquel entonces, nos faltaba una pieza clave en cualquier sitio Web: el buscador del sitio. No podíamos utilizar directamente el buscador original de la Web anterior debido a que había cambiado la tecnología

del sistema de información, desde el sistema original de bases de datos UNIX a un sistema basado en servidor SQL. Migrar el buscador original para adaptarlo a la nueva tecnología requería un tiempo del que no disponíamos. Descartada esta opción, comenzamos a sopesar distintas alternativas, teniendo en cuenta los diferentes tipos de buscador analizados en este mismo capítulo. Finalmente, decidimos optar por un buscador basado en servicio de red, concretamente el servicio Web ofrecido por Google.

Las razones que motivaron esta decisión son:

• La posibilidad de incorporar la avanzada tecnología del motor de búsqueda Google en el buscador del propio Departamento

• La confianza en el proveedor del servicio (Google)

• La facilidad y rapidez previstas tanto para el desarrollo como para el mantenimiento

• La posibilidad de ofrecer búsquedas en distintos dominios: el Departamento, la Escuela Politécnica Superior, la Universidad de Alicante o la WWW.

• La opinión colectiva del equipo técnico y grupo de redes, favorable al modelo de servicios de red y los sistemas emergentes

Una vez tomada la decisión, tras realizar algunas pruebas sencillas con el API de Google, comenzó la fase de desarrollo del buscador, que se completó en apenas una semana de dedicación (no exclusiva) de una persona. El desarrollo consistió en integrar el API de Google en la aplicación Web corporativa, lo cuál se vio enormemente facilitado por la existencia de una biblioteca de acceso al API disponible para la plataforma tecnológica del servidor Web (basada en Java).

Finalmente, tras otra semana de pruebas, una vez observada su estabilidad y corrección y dado que el buscador era la única pieza que faltaba, se trasladó a producción la nueva Web corporativa, en substitución de la original (1995-2005).

7 Infraestructura tecnológica

Para implantar el servicio de búsquedas Google en nuestra aplicación Web, necesitamos de una serie de infraestructuras, que mencionamos a continuación junto a la opción elegida para su implantación en el sitio Web DTIC:

• Servidor Web: Apache 2

• Servidor contenedor de servlets y JSPs: Tomcat

• Conector entre servidor Web y servidor contenedor de servlets y JSPs: mod_jk2

• Máquina virtual + bibliotecas y compiladores Java: JDK 1.5

El código necesario para acceder al servicio Web de Google se encuentra en clases Java que son llamadas desde páginas JSPs, requiriendo para su ejecución del servidor contenedor. Este último recibe peticiones del servidor Web para invocar las páginas JSP, las ejecuta y devuelve el resultado (que ya es código HTML estático) al servidor Web para que este lo remita al cliente o navegador Web.

El kit de desarrollo de Java (JDK) es la base sobre la que se sustenta toda la aplicación, y permite su migración a cualquier otro sistema operativo siempre y cuando exista una versión del JDK disponible para dicho sistema.

8 Conclusiones

Debido a la inmensa cantidad de información presente en la Web, a su continuo crecimiento y actualización, y a la organización dispersa y no orientada a categorías de la misma, resulta imprescindible proporcionar a los usuarios herramientas de búsqueda que les permitan acceder de forma rápida y efectiva a los documentos con la información deseada, sin necesidad de que conozcan a priori su dirección electrónica. Esta necesidad impulsó la creación y evolución

de los actuales motores de búsqueda en Internet (como Google), capaces de resolver las consultas del usuario proporcionando una lista de direcciones de documentos que se ajustan a los criterios de búsqueda (palabras clave, dominio, área temática…). Tales motores requieren grandes infraestructuras tecnológicas para analizar el gran volumen de información presente en Internet con el objetivo de crear índices, establecer categorías temáticas, etc.

Junto a estos motores genéricos, diseñados para la WWW, surgen otros sistemas de búsqueda de ámbito reducido, restringidos a un solo sitio Web, pero más sencillos de desarrollar, implantar y mantener, y con un coste mucho menor en infraestructuras tecnológicas. Se trata de motores de búsqueda específicos para cada sitio Web, y que en ocasiones se elaboran a medida para aprovechar el conocimiento intrínseco sobre el sistema de información del sitio, aumentando así su calidad y rendimiento.

Hasta ahora, las organizaciones que deseaban ofrecer un sistema de búsqueda en su sitio Web debían hacerlo a través de motores de búsqueda de ámbito reducido, o soportar la escalada de costes que supone emplear un buscador genérico. Además, debían proveer ellas mismas el servicio de búsqueda, mediante sistemas ligados directamente a su sistema de información (por ejemplo, módulos de servidor Web).

En la actualidad, las organizaciones cuentan con más opciones gracias a las tecnologías de servicios de red. Así, una empresa que desea ofrecer un servicio de búsqueda en su Web puede integrar en ella un buscador basado en servicios Web, donde el motor de búsqueda es proporcionado por el proveedor del servicio de forma totalmente transparente para el usuario de dicha Web. Adicionalmente, esta posibilidad amplía las capacidades de búsqueda a otros ámbitos, otros sitios Web e incluso la WWW por completo. La única limitación derivada de este método es la incapacidad de realizar búsquedas en zonas privadas del sitio Web, pues los robots exploradores del motor de búsqueda externo no tendrán acceso a ellas.

Por otra parte, para facilitar las búsquedas en zonas privadas y gestionar dichas búsquedas con los niveles adecuados de seguridad, es posible recurrir a los dispositivos de red de búsqueda (search appliance), los cuáles incorporan la avanzada tecnología de un buscador genérico encapsulada en un dispositivo de tipo “conectar y listo”.

Finalmente, la experiencia obtenida en el desarrollo del nuevo buscador para el Departamento de Tecnología Informática y Computación nos ha permitido constatar sobre el terreno las ventajas de un buscador basado en servicios Web: potencia, amplio espectro de búsqueda, flexibilidad, facilidad de integración y mantenimiento mínimo; gran fiabilidad (gracias al proveedor) y ahorro sustancial en mantenimiento —ya no es preciso reescribir el antiguo motor de búsqueda ad hoc.

9 Referencias

1. Arasu A., Cho J., García-Molina, H., Paepcke, A., Raghavan, S. (Stanford University): Searching the Web. ACM Transactions on Internet Technology, (Vol. 1, No. 1, August 2001) 2–43.

2. Albert, R., Barabasi, A.-L., Jeong, H.: Diameter Of The World Wide Web. Nature (Sept. 1999) 401, 6749

3. Pitkow, J., Pirolli, P.: Life, death, and lawfulness on the electronic frontier. Proceedings of the ACM Conference on Human Factors in Computing Systems (CHI ’97, Atlanta, GA, Mar. 22–27), S. Pemberton, Ed. ACM Press, New York, NY, (1997) 383–390.

4. Wills, C. E., Mikhailov, M.: Towards a better understanding of web resources and server responses for improved caching. Proceedings of the Eighth International Conference on The World-Wide Web (1999).

5. Douglis, F., Feldmann, A., Krishnamurthy, B.: Rate of change and other metrics: a live study of the world wide web. Proceedings of the USENIX Symposium on Internetworking Technologies and Systems. USENIX Assoc., Berkeley, CA (1999).

6. Scherpbier, A. et al: ht://Dig – Internet Search Engine Software. WWW. http://www.htdig.org

7. Cutting, D. et al: Apache Lucene Open-Source Search Software. WWW http://lucene.apache.org/

8. Mohr, G. et al: Heritrix open-source, extensible, web-scale, archival-quality web crawler project. WWW http://crawler.archive.org/

9. Chen, Peter P.: The Entity-Relationship Model: Toward a Unified View of Data. ACM Transactions on Database Systems (Vol.1, Nº.1, March 1976) 9-36.

10. Ken A. L. Coar: The WWW Common Gateway Interface Version 1.2 (unpublished Internet draft), (29 May, 1998).

11. Page, L., Brin S.: Google Web APIs. WWW http://www.google.com/apis/

12. Monson-Haefel, R: J2EE Web Services. Addison-Wesley (2004).

13. Page, L., Brin S.: Google Search Appliance. WWW http://www.google.com/enterprise/