Utilizando o WebService do Google

Os WebServices são uma nova e inovadora técnica para a troca de dados via Web e muitas empresas
estão aderindo ao fornecimento e consumo de serviços na web.

Anteriormente aos WebServices, a troca de dados entre empresas normalmente era realizada através de
componentes COM (isso quando era feita de forma, digamos, moderna. Quando não, era DPLDPC -
Disquete para Lá, Disquete para Cá).

Porém, a comunicação de componentes COM uns com os outros em locais distantes de uma Wan ou até
mesmo da internet sempre foi algo complexo. Os componentes COM utilizam o protocolo de rede DCOM,
que por sua vez é baseado no RPC. Consequentemente torna-se necessário ter a porta 135 e mais 20
portas aleatórias abertas para a comunicação entre os componentes. Isso sempre foi uma cadastrofe para a
configuração de Firewalls. Deixar muitas portas abertas é sempre um convite a invasões.

Claro que sempre foi possível determinar quais 20 portas seriam usadas, mas sempre foi uma configuração
demasiadamente complexa, a grande maioria dos administradores de rede não sabia realiza-la.

E eis que surgiu a idéia de fazer a troca de dados entre os componentes COM via XML, apenas pela porta
80.

Mas como um componente COM pode chamar outro via porta 80, como toda a comunicação dos
componentes pode passar por HTTP ? As vezes a resposta correta acaba sendo a mais simples e óbvia :
Basta ter um servidor web com "algo" instalado que sirva como intermediário. Esse servidor Web recebe via
POST um documento XML contendo a descrição do que tem que ser chamado (componente/método),
executa o componente e devolve a resposta em XML. Durante muito tempo foram utilizadas simples
páginas ASP para realizar esse papel de intermediárias. Escrevemos um excelente artigo sobre isso,
chamado "O que é XML", que demonstra a comunicação entre uma aplicação VB e uma página ASP.

Foi neste ponto que começaram a surgir (e serem atendidas) necessidades de padronização desta
tecnologia. Surgiu então o Soap (Simple Object Access Protocol), um padrão de documento XML para fazer
o disparo de um método de um determinado componente existente remotamente e devolver o resultado da
execução deste método. Temos aqui no site um excelente artigo sobre SOAP.

Praticamente junto com o SOAP surgiu mais uma necessidade de padronização : Tornou-se necessário que
a aplicação fosse capaz de identificar automaticamente os métodos existentes em um serviço remoto e a
forma de chama-los, para que assim pudesse não só validar como até mesmo gerar automaticamente os
pacotes SOAP para fazer a comunicação.

Surgiu então o padrão WSDL (WebServices Description Language), que fornece a descrição de tudo que
um WebService possui. Surgiram então Wizards e componentes capazes de utilizar o WSDL para gerar
automaticamente as chamadas SOAP. Realizar a comunicação entre objetos remotos passou a ser
semelhante a chamar um componente qualquer, permitindo até mesmo que o programador se esquecesse
de que a comunicação ocorre via XML na porta 80.

E tudo isso funcionou, sim, no VB 6. Poucos sabem, mas a Microsoft disponibilizou, muito antes do
ambiente .NET ser lançado, um conjunto de wizards e componentes chamados de Soap Toolkit, que
permitiu “transformarmos” componentes COM em WebServices.

Aqui uma observação sobre o termo “transformarmos”. Muitas pessoas que ainda não entenderam
corretamente os WebServices imaginam que isso seja um novo tipo de componente. Isso está longe da
verdade. Os webservices são mais comparáveis a um protocolo de comunicação do que a um componente.
WebService é uma forma de comunicação padronizada entre dois componentes, mas que tipo de
componentes, isso não é importante. Quem vai executar o serviço em si, pode ser qualquer um : Uma
página ASP, um componente COM, enfim, qualquer coisa.
Mas o WSDL ainda não é suficiente para um bom funcionamento dos WebServices na Web. Isso porque
ainda é necessário que o usuário do serviço saiba a localização exata do serviço para poder utiliza-lo.

Para facilitar a descoberta da localização de serviços foi criado o protocolo de Discovery. Através deste
protocolo podemos interrogar um servidor web para descobrirmos os serviços que o servidor possui.

Porém com o protocolo de Discovery ainda teríamos que interrogar servidor por servidor para localizarmos
um serviço. Para evitar isso foi criado o padrão UDDI, um padrão para catálogos públicos de WebServices.
A propria Microsoft mantém um catálogo UDDI, que pode ser pesquisado através do próprio Visual Studio.

Várias empresas já oferecem WebServices, tal como a amazon e o Google. Vamos ver um exemplo da
utilização de WebServices utilizando o WebServices do Google para realizar uma pesquisa no mecanismo
do Google através de uma Windows Application do .NET.

Para o uso do WebServices do Google é necessário se cadastrar (gratuitamente) e baixar um kit de

desenvolvimento do endereço http://www.google.com/apis/ . Vamos porém fazer a demonstração
diretamente com o VB.NET, utilizando uma chave já gerada no momento de um cadastramento no google.

O primeiro passo para fazer uso do WebService é fazer uma referência ao WebService. A referência a
WebServices é um pouco diferente da referência a componentes. Para fazer uma referência a um
WebService devemos utilizar a instrução Add Web Reference, que pode ser encontrada clicando-se com o
botão direito sobre o projeto.

Na tela que se abre precisamos informar o endereço onde se encontra o arquivos WSDL, ou seja, o arquivo
que descreve o serviço do Google.

O endereço do arquivo WSDL do google é http://api.google.com/GoogleSearch.wsdl .

Deve-se ter cuidado ao digitar este endereço pois o servidor do Google é case sensitive. Após digitarmos o
arquivo WSDL será baixado e poderemos clicar no botão Add Reference, que irá adicionar a referência na
aplicação.
Após termos adicionado a referencia ao projeto veremos algo semelhante a uma pasta, mas com um ícone
personalizado (um globo). Esta pasta ganhará um nome baseado no nome do site que originou o arquivo
WSDL (só que ao contrário).

Para simplificar o trabalho podemos clicar sobre o globo e alterar o nome desta pasta, utilizando algo como
Google, por exemplo.

Vamos então criar um Windows Form para realizar a pesquisa no Google. Precisaremos dos seguintes
objetos :

txtPesquisar : Uma caixa de texto onde o usuário poderá digitar o texto a ser pesquisado.
LblTotal : Um label que deverá exibir o total de resultados encontrados.
cmdPesquisar : Botão que irá executar a pesquisa
lstResultado : ListBox que irá exibir o resultado da pesquisa

Nossa programação deverá toda ser realizada no botão cmdPesquisar. Veja como fica o código :
Private Sub cmdPesquisar_Click(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles cmdPesquisar.Click

Dim ChaveLicenca As String ' Variável para guardar a chave de acesso

' Variável para acesso ao WebService do Google

Dim ServGoogle As Google.GoogleSearchService = New _
Google.GoogleSearchService()

' Variável para receber o resultado da pesquisa

Dim ResultadoPesquisa As Google.GoogleSearchResult

' licença de acesso

ChaveLicenca = "tGCTJkYos3YItLYzI9Hg5quBRY8bGqiM"

' Executa a pesquisa no Google

ResultadoPesquisa = ServGoogle.doGoogleSearch(ChaveLicenca, _
txtPesquisar.Text, 0, 1, False, "", False, "", "", "")

' Exibe o total de itens encontrados

lblTotal.Text = ResultadoPesquisa.estimatedTotalResultsCount

End Sub

Observe que a pasta Google passou a ser reconhecida pela aplicação de forma semelhante a um
nameSpace. Passamos a ver as classes expostas pelo WebService do Google como se fossem classes
locais. Desta forma podemos instanciar a classe GoogleSearchService e utilizar o método doGoogleSearch
para realizarmos a pesquisa.

Os principais parâmetros do método doGoogleSearch são a chave de licença de acesso, o texto a ser
pesquisado no google e o valor 1, que indica o número máximo de respostas que desejamos obter. Observe
que a limitação deste número não limita a resposta da propriedade estimatedTotalResultsCount, que
continua mostrando o total de resultados encontrado no banco de dados do Google.

Neste exemplo, porém, estamos apenas exibindo o total de itens encontrados, não os itens propriamente.
Vamos então melhorar um pouco este código :
Private Sub cmdPesquisar_Click(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles cmdPesquisar.Click

Dim ChaveLicenca As String ' Variável para guardar a chave de acesso

' Variável para acesso ao WebService do Google

Dim ServGoogle As Google.GoogleSearchService = New _
Google.GoogleSearchService()

' Variável para receber o resultado da pesquisa

Dim ResultadoPesquisa As google.GoogleSearchResult

'Variável para tratar os resultados obtidos

Dim UmResultado As google.ResultElement

' licença de acesso

ChaveLicenca = "tGCTJkYos3YItLYzI9Hg5quBRY8bGqiM"

' Executa a pesquisa no Google

ResultadoPesquisa = ServGoogle.doGoogleSearch(ChaveLicenca, _
txtPesquisar.Text, 0, 10, False, "", False, "", "", "")

' Exibe o total de itens encontrados

lblTotal.Text = ResultadoPesquisa.estimatedTotalResultsCount

'Laço para tratar cada um dos resultados obtidos

For Each UmResultado In ResultadoPesquisa.resultElements
lstResultado.Items.Add(UmResultado.title)
Next

End Sub

Observem as pequenas mudanças :

 O valor 1 foi alterado para 10, indicando que desejamos obter como resposta um máximo de 10
resultados.
 O tipo ResultElement foi utilizado para fazermos um For/Each na coleção resultElements obtida e
desta forma inserirmos item por item na listbox.

Observe que as classes e métodos utilizados a partir da pasta Google são classes e métodos específicos do
serviço do Google. Cada WebService estará expondo classes e métodos personalizados.

Com esse exemplo podemos ter uma boa noção dos recursos que a utilização de WebServices nos oferece.
São milhares de novas possibilidades em termos de desenvolvimento de software.