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 chamado 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 SubObserve 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 SubObservem 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.
Dennes Torres
MCSD,MCSE,MCDBA
