Saulo.Net > Publicaciones > de investigación > Artículo

Uso de Google Web API, SOAP y WSDL

Saulo Barajas
Doctorado en Tecnologías de las Comunicaciones
Universidad Carlos III de Madrid
E-mail: correo at saulo.net

Abstract. Google proporciona una API que permite acceder a sus servicios de búsqueda desde una máquina remota utilizando el protocolo SOAP. Este trabajo estudia las posibilidades del web service de Google creando una aplicación demostrativa en el entorno de desarrollo web Cocoon.


1 Introducción

Este artículo se acompaña de una presentación y de una aplicación simple desarrollada en Cocoon. El objetivo del trabajo es experimentar con las tecnologías que componen los web services, utilizando como ejemplo la API [1] ofrecida por Google [2] para el acceso a sus servicios de búsqueda.

Google ofrece a través de su sitio web la documentación y archivos necesarios para que una máquina pueda acceder a sus servicios de búsqueda. Para ello es necesario un registro previo que proporciona una clave única. Cada servidor, identificado por la clave recibida de Google, puede realizar un máximo de 1000 peticiones por día. Esto evita que se puedan utilizar estas funcionalidades para ofrecer un servicio de búsqueda paralelo al de Google desde un servidor web distinto.

El web service de Google se ofrece gratuitamente a investigadores para que experimenten con la tecnología que lo sustenta. En estos momentos, no hay versión comercial.

El API de Google se ofrece en un archivo comprimido ZIP compuesto por distintos ficheros, entre los que se encuentran un archivo WSDL (Web Services Description Language, lenguaje de descripción de servicios web), un archivo .jar con clases Java junto a su documentación y aplicaciones demostrativas en Java y Microsoft .Net.

La aplicación Java funciona desde línea de comando y permite hacer búsquedas, solicitar sugerencias de un término mal tecleado y ver la caché de Google para cierta URL.

Realmente nuestro objetivo es poder acceder a estos servicios pero desde un navegador web, no desde la línea de comandos. Para ello necesitamos configurar un servidor web que realice las consultas necesarias a Google mediante su API. El usuario, desde su navegador, únicamente verá que accede a un sitio web (http://servidor-de-ejemplo.com), en el cual puede realizar una consulta de búsqueda y recibir los resultados dentro del mismo sitio. El usuario no sabría que internamente se utiliza una consulta a Google si nosotros no se lo indicamos. Los servicios web posibilitan que distintos servidores hablen entre sí para solicitar y recibir servicios, de forma transparente al cliente que contacta con uno de los servidores.

 

2 Plataforma de desarrollo

Para la implementación de la aplicación se ha escogido el entorno de desarrollo web Cocoon. Cocoon es un producto open source perteneciente al proyecto Apache Cocoon [3].

La versión de Cocoon utilizada, 2.1.5, incluye todo lo necesario para su puesta en marcha (servidor web y contenedor de servlets), excepto el entorno de desarrollo de Java (J2SE) [4] que debe estar instalado  previamente. En nuestro caso, utilizamos la versión 1.4.2 de J2SE. El entorno puede desplegarse tanto en una máquina Windows como en un sistema Unix.

Cocoon es un entorno basado en Java enfocado a la construcción de aplicaciones web basadas en componentes y en la separación de presentación y contenido. El elemento de construcción de las aplicaciones es el pipeline o tubería, el cual realiza una serie de transformaciones a una petición hasta generar un documento de salida. La representación intermedia de los datos es en XML. Estos datos atraviesan una serie de elementos de procesado hasta producir el documento de salida. La salida normalmente será una página HTML, aunque también podría ser un archivo PDF o tener otros formatos.

 

3 Interfaz WSDL de Google

Google proporciona un archivo WSDL [5] que describe las operaciones soportadas. Este fichero se encuentra entre los archivos descargados de la API, aunque también se ofrece de forma online [6].

La descripción WSDL indica que se soportan tres operaciones: doSpellingSuggestion, doGetCachedPage y doGoogleSearch. La primera permite solicitar a Google una sugerencia de escritura correcta para un término mal tecleado. La segunda devuelve la caché almacenada de Google para una URL dada. Por último, doGoogleSearch, se corresponde con el servicio tradicional de búsquedas en la Web.

Cierto es que Google podría ofrecer un mayor número de operaciones, como el acceso a grupos de noticias o búsqueda de imágenes. Sin embargo, la API está fechada en 2002 y no parece que haya más interés que el de ofrecer un número limitado de operaciones como demostración del sistema.

A continuación se estudian las tres operaciones soportadas:

 

3.1 Operación doSpellingSuggestion

Su manejo es el más sencillo de las tres. Para su invocación requiere dos entradas:

Su salida es:

 

3.2 Operación doGetCachedPage

Su interfaz también es muy sencilla. Requiere dos entradas (key y url) y devuelve como salida la caché almacenada para la URL indicada. Entradas:

Su salida es:

 

3.3 Operación doGoogleSearch

Esta operación es la que admite un mayor número de opciones de configuración. Entre las entradas, las más importantes son la clave y la consulta solicitada, pero también hay otras que debemos conocer. Se explican brevemente todas a continuación.

La salida se devuelve mediante el elemento return del tipo complejo GoogleSearchResult. Este tipo está formado por los siguientes elementos:

Los elementos anteriores proporcionan información general de toda la búsqueda. Pasamos ahora a describir los elementos del tipo complejo ResultElement, con información relativa a un resultado concreto.

o        summary. Resumen escrito por un editor del directorio, en caso de que el sitio esté incluido en el directorio.

o        URL. Identificador del documento.

o        snippet. Fragmento de texto del documento donde normalmente aparecerán los términos buscados.

o        title. Título del documento.

o        cachedSize. Tamaño de la página almacenada en caché. Si no está almacenada, no devuelve nada.

o        relatedInformationPresent. Indica si está soportada la búsqueda de documentos similares para la URL de este resultado.

o        hostName. Indica el nombre del host en caso de que se haya mostrado ya al menos 1 resultado de ese mismo host.

o        directoryCategory. Tipo complejo que indica la categoría del directorio donde está incluido el sitio.

o        directoryTitle. Título de la categoría del directorio.

 

4 Aplicación simple

En este apartado describimos las cuestiones de diseño de la aplicación desarrollada en Cocoon.

Una vez que conocemos la descripción WSDL de las operaciones de Google, podemos generar peticiones SOAP y procesar los mensajes de respuesta recibidos.

El protocolo SOAP (Simple Object Access Protocol, protocolo simple de acceso a objetos) [7] permite la comunicación entre servidores. SOAP especifica el formato de los mensajes para que una máquina solicite un servicio a otra máquina y reciba una respuesta. En nuestro caso, configuraremos un servidor web para que realice peticiones vía SOAP al servidor de Google y procese los mensajes de respuesta.

Para generar los mensajes SOAP desde Cocoon hemos encontrado 2 alternativas. La primera es utilizar las clases Java suministradas en la API de Google. La segunda es generar los mensajes SOAP desde Cocoon ajustándonos a la descripción WSDL proporcionada.

 

4.1 Invocación de operaciones desde Java

Google proporciona una API Java formada por una estructura de clases en un archivo .jar y documentación en formato HTML. También se incluye un ejemplo de uso que funciona bajo línea de comando.

Las clases Java encapsulan en métodos todo el procesamiento del web service. Por ejemplo, para comprobar la corrección de un término basta con invocar el método doSpellingSuggestion (phrase) que recibe un String y devuelve un String con el término corregido.

Debido a la posibilidad de incluir código Java en páginas XSP de Cocoon, resulta sencillo invocar los métodos y procesar los resultados. Estos resultados se colocarán en elementos XML para que puedan ser presentados en HTML después de convertirlos mediante una hoja de estilos XSLT.

El archivo googleapi.jar debe ubicarse en un directorio visible por Cocoon. En nuestro caso, bastó con que estuviese presente en el directorio java/j2sdk/jre/ lib/ext antes de arrancar Cocoon.

Cada una de las clases requeridas por la aplicación XSP debe incluirse una a una mediante elementos <xsp:include>.

Los archivos de la aplicación corregir.xsp y vercache.xsp utilizan este procedimiento para comprobar la corrección de un término y ver la caché de una URL, respectivamente.

 

4.2 Invocación de operaciones desde XSP

El procedimiento descrito en el apartado anterior es válido sólo en el caso del web service de Google, puesto que se suministran clases Java que encapsulan todo el diálogo SOAP entre las máquinas.

Sin embargo, esto no será lo usual en otros web services, por lo que necesitaremos confeccionar nosotros mismos los mensajes SOAP y procesar sus respuestas, según la correspondiente descripción WSDL.

Cocoon facilita esta tarea mediante la funcionalidad “SOAP logicsheet” que se invoca en páginas XSP con el elemento <soap:call>. Este elemento genera el mensaje SOAP enviando los elementos que contiene, lo ejecuta e incluye la respuesta en su lugar.

Una vez tenemos la respuesta en formato XML, se puede procesar mediante una hoja de estilos XSLT y convertirla así a HTML.

Este procedimiento se ha utilizado en el archivo buscar.xsp de la aplicación. En este caso no se utilizan las clases Java contenidas en el archivo googleapi.jar. De la misma forma, se podrían haber realizado los archivos xsp de las otras dos operaciones sin necesidad de utilizar las clases Java suministradas por Google, pero hemos creído conveniente ofrecer ejemplos de ambos mecanismos para ilustrar las posibilidades de Cocoon y Google Web API.

 

4.3 Mapa de la aplicación

La aplicación desarrollada utiliza 4 pipelines, uno por cada página creada. El primero es sencillamente para la invocación de una página estática con un formulario que solicita una consulta al usuario.

Los otros tres se corresponden con las operaciones de comprobación de errores en la escritura, búsqueda en la web y visualización de caché.

Para cada una de ellas se utiliza una página XSP como generador, una hoja de estilos XSLT como transformador y un serializador para generar el código HTML.

La aplicación se ha dispuesto de tal manera que se pueda comenzar verificando la corrección de un término, continuar buscando ese término en la Web y, finalmente, consultar la caché de alguno de los resultados.

 

5 Conclusiones

El API de Google resulta muy interesante para comenzar a experimentar con web services. Incluye una buena documentación para ponerlo en marcha. Se podrían realizar incluso consultas a Google sin ni siquiera tener conocimientos de WSDL y SOAP. Sin embargo, en este trabajo hemos querido ir más allá y analizar todas las posibilidades que se ofrecen.

Como plataforma de desarrollo, se ha optado por Cocoon por ofrecer una muy buena integración con XML y SOAP. Una vez se dominan las bases de su funcionamiento, resulta sencillo realizar una petición vía SOAP y devolver sus resultados en una página HTML.

 

Referencias

[1]     Google Web APIs: http://www.google.com/ apis/

[2]     Google: http://www.google.com/

[3]     The Apache Cocoon Project: http://cocoon. apache.org/

[4]     Java 2 Platform, Standard Edition (J2SE): http://java.sun.com/j2se/

[5]     Web Services Description Language (WSDL): http://www.w3.org/TR/wsdl

[6]     Descripción WSDL del web service de Google: http://api.google.com/GoogleSearch.wsdl

[7]     Simple Object Access Protocol (SOAP): http://www.w3.org/TR/soap/