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

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
middleware)
infraestructuras
y
personal
(servidores,
para
su
plataformas
desarrollo,
software
implantación
y
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
http
Nombre del
documento
Puerto del servidor
Ruta de directorios
Protocolo
Nombre DNS del
servidor
(o dirección IP)
en la Web.
:// www.dtic.ua.es : 80 /grupoM/ index.htm
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).
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.
Crawlers
Usuario
GET
C
l ta
su
on
Motor de
búsqueda
s
Cliente
os
ltad
P
HTT
Repositorio
de páginas
u
Res
Internet
Ranking
HTTP GET
HTT
P GE
Módulo de
indexado
T
Servidores
HTTP
(World Wide Web)
a
Re
Control de
crawlers
t
en
lim
ión
ac
b
ad
as
a
en
o
us
de
ot
lm
or
Módulo de
análisis de
recopilaciones
Índices
Texto
Estructura
Utilidad
Retroalimentación texto/estructura
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).
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 (19952005) 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
extremadamente difícil cuando no imposible.
del
sitio
Web
sería
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
relacionadas).
el
resultado
de
la
búsqueda
(lista
de
URLs
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).
Registro UDDI
Service Broker
1 Publicación
3
Hoja WSDL
2 Búsqueda
1
Solicitud UDDI
2
3 Descubrimiento
Hoja WSDL
4 Consumo
Mensajes SOAP
4
Servicio Web
Service Provider
Aplicación Web
Service Requester
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.
• 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.
3.
Pitkow, J., Pirolli, P.: Life, death, and lawfulness on the electronic frontier.
Nature (Sept. 1999) 401, 6749
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.
7.
Cutting, D. et al: Apache Lucene Open-Source Search Software. WWW
8.
Mohr, G. et al: Heritrix open-source, extensible, web-scale, archival-
9.
Chen, Peter P.: The Entity-Relationship Model: Toward a Unified View of
http://www.htdig.org
http://lucene.apache.org/
quality web crawler project. WWW http://crawler.archive.org/
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/