Na primeira parte dessa série, expliquei os problemas que o desenvolvedor enfrentam ao tentar extrair dados públicos e iniciamos um exemplo com a motivação de se tentar plotar num mapa os endereços de feiras livres de São Paulo, no dia da semana e zona da cidade que o usuário escolhesse. O principal resultado que obtivemos até esse ponto foi uma Open Table da Yahoo Query Language que nos permite realizar a pesquisa para obter os endereços. Sucintamente, ao executar a seguinte query:

USE "http://github.com/lfcipriani/yql-feira-livre-sp/raw/master/yql-feira-livre-sp.xml" AS feiras;

SELECT * FROM feiras WHERE zone = 'SUL' AND dayOfTheWeek = 'DOMINGO';

Obtemos o resultado:

<markets>

   <market>

     <dayOfTheWeek>DOMINGO</dayOfTheWeek>

     <address>RUA  CONDE DE PORTO ALEGRE, Sao Paulo, Brazil</address>

   </market>

   <market>

     <dayOfTheWeek>DOMINGO</dayOfTheWeek>

     <address>AV   AMADEU DA SILVA SAMELLO, Sao Paulo, Brazil</address>

   </market>

   ...

</markets>

Você pode relembrar como funciona o YQL executando esse exemplo diretamente no YQL Console.

A proposta dessa segunda parte é utilizar esse resultado, a conversão do HTML em uma estrutura XML fácil de ser lida por um software, no Yahoo Pipes e plotar o mapa. Dessa forma o usuário pode facilmente saber se tem uma feira livre perto da casa dele, uma vez que agora a informação está num formato mais apropriado.

Yahoo Pipes

Da própria definição no site: “Pipes é uma ferramenta poderosa de composição para agregar, manipular e misturar conteúdo (feeds, RSS, Atom, etc) da Web”.

O legal do Yahoo Pipes é que o usuário não precisa ter conhecimentos avançados de programação ou de como manipular vários formatos, pois a interface é bem fácil de usar. Basta criar conexões entre vários módulos (daí o nome Pipes), sendo que cada módulo faz alguma ação sobre o conteúdo que está passando por ele. A idéia é combinar vários desses módulos para no fim obter um novo fluxo de informações, ou um fluxo enriquecido, modificado.

Nosso objetivo é enriquecer o conteúdo, pois queremos pegar meros endereços e representá-los como pontos em um mapa. Então vamos direto ao ponto!

O mashup de feira livre

O Pipes que vamos criar deve fazer o seguinte:

• Receber do usuário o dia da semana e o zona da cidade;
• Executar a query YQL para obter os endereços de cada feira livre;
• Para cada endereço, realizar um geocoding para obter as coordenadas geográficas;
• Plotar essas coordenadas em um mapa.

Para ajudar no entendimento, você pode visualizar o Pipes de Feira Livre enquanto lê cada passo abaixo (para ver o “código-fonte” do Pipes você precisa estar logado com algum id do Yahoo). Se tiver dúvida no comportamento de um módulo, clique nele e observe a barra inferior apresentando o resultado parcial do mashup.

Recebendo do usuário o dia da semana e zona da cidade

As entradas de usuários podem ser feitas utilizando o Text Input Module, veja a figura abaixo apresentando como configuramos este módulo para as duas entradas necessárias no Pipes de feira livre.

Como se pode ver, com o Text Input, basta configurar o nome da variável, o texto que aparecerá para o usuário (prompt), um opcional valor default e por fim um valor de debug, utilizado quando o criador do Pipes está testando os resultados. Cada entrada dessa é jogada para um String Builder Module, cujo objetivo é bem simples, concatenar strings. Veja que é bem simples, no nosso caso, bastou conectar a saída do Text Input na parte da string que eu quero gerar. A string final obtida com esse módulo será a query YQL que eu vou executar. Aonde? No YQL Module, é claro. Vamos dar uma olhada como fica essa segunda parte do Pipes de feira livre.

Executando a query YQL na Open Table de feira livre

A saída do String Builder é plugada no módulo que executa YQL’s, como mostra a figura acima. O resultado da execução da YQL é uma estrutura de árvore, hierárquica, ou seja, nesta situação, há vários níveis entre a raiz da árvore e a informação que nos interessa (a estrutura XML apresentada no início desse artigo), portanto, temos que usar um Sub-element Module.

O Sub-Element apresentado na figura irá pegar a árvore de resultado retornada pela YQL query e vai retornar apenas a sub-árvore indicada no campo dele, isto é, queremos apenas a sub-árvore que no fim será representada por uma lista de mercados (item.market), que por sua vez contêm dia da semana e endereço de uma feira livre. Nesse ponto o Pipes mostra a sua eficiência, quando focamos o campo do módulo Sub-Element, o Pipes abre um dropdown menu contendo todos os nós dessa árvore retornada pela query, facilitando muito a vida do criador do mashup.

Por fim, temos um Rename Module, e o objetivo dele é renomear atributos de um feed. Esse passo é importantíssimo para a criação desse mashup, pois o Yahoo Pipes, assim como a própria definição dele diz, é um agregador de feeds (RSS, Atom, etc). Portanto, o módulo Rename está sendo usado justamente para esta causa, que é criar o menor feed possível que o Pipes entenda, com título da entrada e descrição.

Se não realizássemos essa renomeação, o Pipes (e outros consumidores desse Pipes de feira livre) não saberia como consumir os dados. Então guarde essa dica: mesmo com a capacidade de trabalhar com várias formatações de dados, todo Pipes deve “cuspir” feeds, dessa maneira você facilita até que outros criadores de Pipes reutilize o seu mashup. Só existe uma exceção para essa regra e vamos apresentá-la na próxima etapa.

Realizando o geocoding para obter as coordenadas geográficas

Esta etapa foi a mais complicada. Inicialmente, colocamos um Loop Module, cujo objetivo é iterar sobre os elementos do feed e realizar alguma operação neles. Essa operação pode ser qualquer outro módulo do Pipes. Olhando no Loop da figura acima, temos o Google Maps Location Extractor, que se você procurar nos módulos padrões disponíveis do yahoo Pipes você não vai encontrar. A explicação é simples, esse módulo é um outro Yahoo Pipes criado por mim. Esse eu não vou explicar como eu fiz, vou apenas passar a URL pra vocês e aí fica como “lição de casa” entender como ele funciona, OK? Aí vai: http://pipes.yahoo.com/lfcipriani/gmapslocationextractor.

O único detalhe importante que vale o comentário é que esse Pipes não retorna um feed válido, mas apenas uma estrutura contendo o resultado da geolocalização, e assim, fugindo da regra citada na etapa anterior. Fiz isso porque o objetivo principal desse Pipes de geolocalização é ser reutilizado somente dentro de outro Pipes, e com restrição na forma de utilizar o seu resultado.

Mas aí vocês podem se perguntar: peraí, o Yahoo Pipes já não tem um módulo de extração de geolocalização? Sim, ele tem, e se chama Location Extractor Module, e para utilizá-lo basta plugá-lo em qualquer saída de feed que ele irá pesquisar por coordenadas geográficas nos campos do feed que são endereços. Se usássemos ele não precisaríamos criar esse Loop, pois ele itera automaticamente nos feeds, mas então porque não usamos?

A resposta é simples, após alguns testes com esse Location Extractor eu percebi que as coordenadas que ele encontrava não era do endereço correto, ou seja, o geolocation não era confiável para os endereços de feiras de São Paulo, talvez ele seja mais eficiente para outras situações. Eu testei alguns endereços no Google Maps Geocoding Webservice e ele foi capaz de acertar mais, mas ainda assim comete alguns erros de vez em quando (vocês podem ver ao executar o Pipes que alguns endereços caem em outras cidades, mas não deveria porque as feiras são todas na cidade de São Paulo). Enfim, como o Google Maps se comportou melhor, não me prendi ao Location Extractor que está disponível no Yahoo Pipes e decidi criar um outro usando um geocoding melhor para a minha necessidade.

Plotando no mapa

O Yahoo Pipes possui uma convenção para coordenadas geográficas, dessa forma, feeds que possuem os campos nesse padrão são automaticamente mapeados quando o Pipes é executado (e você achando que ia ter que aprender a API do Yahoo Maps, hein! ).

O jeito mais simples de utilizar esse padrão é criar o nó y:location e colocar dentro dele os atributos y:location.lat e y:location.lon (você também pode incluir outras informações). Como o webservice de geocoding do Google Maps não me retorna esses campos no formato que o Yahoo Pipes precisa, eu utilizo o Rename Module novamente para renomear a longitude para a forma correta e pronto! Jogo a saída disso tudo no Pipe Output e o Pipes está finalizado.

O resultado final

Se no modo de edição clicarmos no Pipe Output, poderemos ver na barra de debug inferior da interface do Yahoo Pipes a seguinte estrutura de resultados:

Esse é o feed final que o usuário vai obter ao executar o Pipes, que pode ser utilizado assim como qualquer outro feed na Web: assinar em um feed Reader, consumir com outro Pipes (ou software), manipular as entradas, plotar em outro tipo de mapa, Google Earth, [coloque o que quiser aqui].

Você também pode acessar o Pipes de Feiras Livres de São Paulo pelo próprio site dele, e aí obterá um resultado parecido com esse:

Obs.: Lembro vocês que o serviço da prefeitura que serve os endereços é bem instável. Eu tive problemas para acessar principalmente após a meia-noite nos dias da semana e durante o dia todo no fim de semana.

Recapitulando

Na primeira parte desse artigo, focamos em como usar a Yahoo Query Language para oferecer uma linguagem parecida com a SQL para transformar representações, no caso, um HTML desestruturado para um XML conciso e estruturado de forma melhor para ser processada por um software.

Já nesta segunda parte, utilizamos o resultado dessa query YQL para plotar os endereços das feiras livres de São Paulo. O interessante é que isso foi feito inteiramente dentro do Yahoo Pipes, sem a necessidade de escrever uma linha de código.

A minha recomendação de uso para esses serviços é a seguinte: claro que se formos construir uma aplicação mais robusta, processando muito mais dados e que terá uma alta carga num servidor, o Yahoo Pipes e talvez até o YQL não sejam as maneiras apropriadas de se fazer os mashups. Porém, como no caso do exemplo desse artigo (localização de feiras livres), a proposta for apenas de criar um mashup rápido para se ter um ganho no entendimento e visualização de uma informação, que não vai ser utilizada para fins muito críticos, aí sim, esses tipos de serviços são excelentes, pois os resultados vêm rapidamente.

Enfim, sugiro dar uma olhada nos Pipes existentes, tem sempre uma idéia interessante pra ser observada e é muito fácil ver como ela foi implementada, graças a interface que o Yahoo criou para isso. E se você criar ou já criou um Pipes, coloque num comentário desse artigo para que os leitores possam acessar também.

Menos comum mas muito importantes, mashups que utilizam dados públicos (aqueles que se utilizam de dados de órgãos públicos ou outras instituições com esse mesmo caráter) também são criados, porém os desenvolvedores enfrentam muitas dificuldades, por exemplo:

• Falta de interesse da população e dos usuários da Web;
• Nem todos os dados necessários estão publicados ou disponíveis para acesso;
• Algumas vezes os dados podem não estar atualizados ou serem pouco confiáveis;
• Servidores dos dados podem ser mal administrados e os dados podem ficar indisponíveis temporariamente;
• A forma como os dados são disponibilizados pode ser “ilegível” ou “burocrática” para um software;

Eliminar essas dificuldades depende de boa vontade desses órgãos públicos e dos cidadãos. Enquanto não temos uma solução, nós, como desenvolvedores, podemos utilizar ferramentas e nossa criatividade para extrair esses dados, certo? Sendo assim, vamos implementar uma simples extração de dados utilizando 2 ferramentas que facilitam a nossa vida: a Yahoo Query Language (YQL) e o Yahoo Pipes (Y!Pipes).

Nessa primeira parte, o foco será apenas no YQL, mas eu pretendo publicar a parte do Y!Pipes em 1 dia ou 2.

A motivação

foto por Chico Ferreira

Eu costumo ir sempre numa mesma feira livre, aqui em São paulo, nos sábados. Porém, sempre quis saber se existem feiras livres mais próximas de casa e os dias em que elas ocorrem. Tinha duas opções, ou saía de casa todo dia e andava pela redondeza procurando feiras ou dava uma “googlada” para ver se encontrava localização delas aqui em São Paulo. Acabei encontrando o seguinte site da prefeitura:

http://www.prodam.sp.gov.br/semab/mercados/pesqt.htm

Sensacional, funciona direitinho e escolhendo região e dia da semana eu obtenho uma lista com os endereços. Aí é que aparece mais um problema, eu reconheci poucas ruas e decidi procurar no Google Maps, mas isso não é muito produtivo, tinha que copiar rua por rua e isso se tornou uma tarefa tediosa. Então decidi colocar a mão na massa pra plotar todos esses endereços num mapa, utilizando o que a Web oferece.

Os problemas dessa fonte de dados

Não apenas o design da página, mas todo o código HTML parece que foi criado nos anos 90. Ele utiliza frames, tags <center>, <font>, <table>’s aninhadas, em resumo, uma tristeza para qualquer programador que precisar fazer um parsing. Vamos dar uma olhada na situação:

<HTML>

<HEAD></HEAD>

<BODY>

<HEAD><TITLE>ENDERECO DAS  FEIRAS POR DIA  </TITLE>

</HEAD>

<BODY  bgcolor="f9cd8a">

<!--BODY background="/img_feiras/feiras.GIF"--><br>

<center>

<!--img src="/img_feiras/logo1.GIF" border=0 align=top><BR>

<font color=#006666 size=5><B><I>RELAÇÃO DE FEIRAS</I></B></FONT><BR-->

</CENTER>

<PRE>

<center><table border=0><tr><td>

 <CENTER><TABLE BORDER=1 background=http://www.prodam.sp.gov.br/semab/mercados/img_feiras/Gray.jpg><TR><TD ALIGN=CENTER COLSPAN=4><FONT COLOR=#006666  SIZE=5>ZONA CENTRAL</FONT></TD></TR><TR><TD ALIGN=CENTER><FONT COLOR=Black Size=3><b>DIA</b></TD>

 <TD><FONT COLOR=Black Size=3><b>ENDERECO</b></TD>

 <TD ALIGN=CENTER><FONT COLOR=Black Size=3><b>NRO.</b></TD>

 <TD ALIGN=CENTER><FONT COLOR=Black Size=3><b>BAIRRO</b></TD></TR>

 <TR>

 <TD ALIGN=CENTER><FONT COLOR=Red Size=2>DOMINGO</TD>

 <TD><FONT COLOR=Red Size=2>RUA  SANTO AMARO                  </TD>

 <TD ALIGN=CENTER><FONT COLOR=Red Size=2>  S/N&nbsp;</TD>

 <TD ALIGN=CENTER><FONT COLOR=Red Size=2>BELA VISTA          </TD>

 </TR>

 ... omiti de propósito algumas linhas que se repetem ...

Além disso, o servidor nem sempre está disponível (percebi que de fim de semana a instabilidade aumenta) e o tempo de execução médio de requisições que eu enfrentei foi de 10 a 15 segundos. Solução para esse problema, só cacheando todos os dados em outro servidor (não, obrigado) ou quando eles realizarem melhorias na infraestrutura (mas convenhamos, isso não deve ser prioridade).

O objetivo

A tarefa parece simples:

• Executo uma requisição POST passando os parâmetros de zona e dia da semana (via wget, curl, API HTTP de qualquer linguagem);
• Realizo um DOM parsing no HTML retornado, e recupero a tabela contendo os endereços (via navegação de DOM, XPATH);
• Para cada endereço, faço um geocoding usando qualquer API disponível para obter as coordenadas geográficas (via Yahoo Maps, Google Maps, Geonames, etc);
• Jogo essas coordenadas em qualquer serviço de mapas (via Yahoo Maps, Google Maps, etc).

Tinha apenas uma preguiça premissa: não queria usar nenhum programa feito por mim nem por ninguém, mas sim apenas serviços na Web.

Yahoo Query Language

A Yahoo Query Language ou apenas YQL, é uma linguagem parecida com a SQL, largamente utilizada nos bancos de dados, porém cujo objetivo é acessar fontes de dados na Internet. Por exemplo, uma query possível de se realizar com ela é:

SELECT * FROM LOCAL.search WHERE query="sushi" AND location="san francisco, ca"

Bem simples, essa query vai pesquisar por restaurantes em San Francisco, California, que servem sushi. O interessante é que o serviço da YQL centraliza as fontes de dados e fornece uma interface única para todos eles, facilitando a vida do programador, pois fica muito mais fácil utilizar os resultados das queries e também de combinar vários serviços. Se você ainda não conhece, sugiro dar uma brincada com o YQL Console, que possui inúmeros exemplos.

Para os serviços que não possuem tabelas disponíveis, o YQL nos dá duas opções. A primeira é simples, basta executar a seguinte query:

SELECT * FROM html WHERE url="[qualquer URL aqui]" AND xpath='[uma query XPATH aqui]

Com essa query obtemos o resultado da query XPATH no código HTML no formato JSON ou XML. Contudo, essa opção não nos ajuda, pois precisamos realizar uma requisição POST e passar parâmetros para ela.

Nos resta a segunda opção, Open Tables!

YQL Open Tables

Mais interessante que a própria YQL, são as YQL Open Tables, que permitem expor qualquer serviço ou API na web como uma tabela na YQL. Basicamente, para isso, basta criar a especificação de sua Open Table com XML, que pode inclusive possuir código javascript para permitir uma manipulação mais flexível dos dados.

Vamos então ver como fica a nossa Open Table para o caso da nossa fonte de dados de feiras livres em São Paulo. Se você está ansioso, pode acessar o código fonte final no GitHub.

O primeiro passo é colocar a meta-informação da sua Open Table, para que os usuários dela possam saber a forma correta de utilizá-la. Todos as tags XML utilizadas estão detalhadas na documentação de Open Tables da YQL, portanto, vou explicar somente aquelas mais relevantes para o entendimento deste artigo.

<table xmlns="http://query.yahooapis.com/v1/schema/table.xsd">

 <meta>

 <author>Luis Cipriani (@lfcipriani)</author>

 <description>

 Busca por Feiras Livres em São Paulo, por dia da semana e zona da cidade.

 - As zonas possíveis são: CENTRAL, NORTE, SUL, LESTE e OESTE.

 - Os dias da semana possíveis são: DOMINGO, TERCA, QUARTA, QUINTA, SEXTA, SÁBADO.

 - Deixe o dia da semana em branco para pesquisar em todos os dias de uma vez só.

 </description>

 <sampleQuery><![CDATA[ SELECT * FROM {table} WHERE zone = 'CENTRAL' ]]></sampleQuery>

 <sampleQuery><![CDATA[ SELECT * FROM {table} WHERE dayOfTheWeek = 'DOMINGO' AND zone = 'OESTE' ]]></sampleQuery>

 <documentationURL></documentationURL>

 </meta>

</table>

Agora precisamos criar a parte da especificação que cria a estrutura da query que desejamos expor para os usuários:

<table>

 <meta>...</meta>

 <bindings>

   <select itemPath="" produces="JSON" >

     <urls>

       <url>http://www3.prefeitura.sp.gov.br/feiras/feiras.asp</url>

     </urls>

     <inputs>

       <key id="dayOfTheWeek" type="xs:string" paramType="variable" default="todos" />

       <key id="zone" type="xs:string" paramType="variable" required="true" />

     </inputs>

     <execute>...</execute>

   </select>

 </bindings>

</table>

Dentro da tag <bindings> podemos ter as tags <select>, <insert>, <update> e <delete>, dependendo do tipo de queries que queremos criar, no nosso caso, somente uma query SELECT. Deixamos o attributo itemPath porque não queremos colocar nenhum namespace precedendo a resposta retornada e escolhemoso JSON como format padrão no atributo produces.

Na tag <url> colocamos a URL do serviço que vamos acessar, no caso, essa é a URL que vamos fazer a requisição POST e passar os parâmetros necessários para obter a lista de endereços de feiras livres.

Só nos falta agora definir quais os parâmetros desejamos na query, o que é feito pela tag <key>. No exemplo acima, ao atribuir o tipo variable para as duas tags, eu estou informando que dayOfTheWeek e zone são duas variáveis que podem (ou devem) ser utilizadas como cláusulas no WHERE da query.

Munido de todas as configurações de nossa query, se o tipo de fonte de dados utilizado exigir, podemos ainda incluir um código javascript para permitir um manuseio mais flexível dos dados obtidos pela query. No nosso caso, nós precisaremos fazer isso, pois a forma como o HTML é entregue após essa requisição não é muito fácil de lidar. Além disso, desejamos que ao executar essa query, o desenvolvedor obtenha apenas os dados necessário, então seria interessante retornarmos os dados limpos e bem estruturados.

Queremos, a partir do código HTML da fonte de dados apresentado acima, obter o seguinte:

<markets>

   <market>

     <dayOfTheWeek>DOMINGO</dayOfTheWeek>

     <address>RUA  CONDE DE PORTO ALEGRE, Sao Paulo, Brazil</address>

   </market>

   <market>

     <dayOfTheWeek>DOMINGO</dayOfTheWeek>

     <address>AV   AMADEU DA SILVA SAMELLO, Sao Paulo, Brazil</address>

   </market>

   ...

</markets>

Vamos então analisar por partes o código javascript, que é incluído dentro da tag <execute>. Veja bem que vamos apenas focar nas partes mais importantes:

var postData = "zona="+ zone +"&dia=" + dayOfTheWeek;

var data = request.accept('text/html').

    contentType("application/x-www-form-urlencoded").

    post(postData).response;

var xdata = y.xpath(data, "//font[@color='Red']");

Como a nossa requisição é do tipo POST e por padrão uma Open Table faz um GET, precisamos usar o objeto request fornecido pelo YQL para realizar a requisição manualmente. O objeto request possui a propriedade de chaining, então fica bem tranquilo realizar a requisição. Só lembrando que a URL utiliza é aquela especificada lá na tag URL.

Depois pegamos o resultado dessa requisição e realizamos uma query XPATH. Diante do HTML totalmente sem estrutura que recebemos da requisição, a query XPATH que busca os resultados que mais precisamos foi:

//font[@color='Red']

Ou seja, todas as tags do tipo <font> que possuem o atributo color igual a “Red”. Se o HTML fosse semanticamente válido com certeza essa query seria diferente e até faria mais sentido, mas ao extrair dados públicos é bastante comum se deparar com esse tipo de estrutura. Mas é aí tá a diversão do negócio!

Calma que ainda não acabou, agora temos que utilizar o resultado da query XPATH e recuperar dessa lista o dia da semana e estruturar o endereço de uma forma que seja ideal para o geocoding.

default xml namespace = '';

for each (var item in xdata) {

  if (i == 0) {

    day = item.toString().trim();

  } else if (i == 1) {

    address += item.toString().trim() + ", ";

  } else if (i == 2) {

    number = item.toString().trim();

    if (number != "S/N" && number.length != 0) {

      address += number + ", ";

    }

  } else if (i == 3) {

    address += "Sao Paulo, Brazil";

    marketList.push({day: day, address: address});

    address = "";

    i = -1;

  }

  i++;

}

No código acima, nós iteramos sobre o resultado da query anterior. Para cada 4 items, o primeiro é o dia da semana, e do 2o. ao 4o. constitui o endereço, que incrementamos em uma variável address para no final, montarmos um JSON que possui os atributos relevantes: dia da semana e endereço. Um leitor atento vai perceber que tem código meio estranho nesse trecho acima, o fato é que o YQL aceita na tag <execute>, além do javascript, o E4X (Ecmascript for XML), que adiciona suporte nativo ao manuseio de XML no javascript e é por isso que existe a declaração de namespace default xml namespace = ''. Vamos dar uma olhada na última parte desse algoritmo para entender melhor como o E4X funciona.

default xml namespace = '';

var result = <markets />

for (i = 0; i < marketList.length; i++) {

  result.markets += <market><dayOfTheWeek>{marketList[i].day}</dayOfTheWeek><address>{marketList[i].address}</address></market>;

}

response.object = result;

A resposta da query YQL deve ser enviada para a variável response.object e deve ser criada com o E4X, e veja que isso é feito escrevendo XML diretamente no código javascript. Esse algoritmo foi necessário apenas para converter a estrutura HTML do site de pesquisa de feiras livres para um formato XML mais adequado para ser “lido” por um software.

Pronto! A Open Table está pronta, um exemplo de query que podemos fazer é:

USE "http://github.com/lfcipriani/yql-feira-livre-sp/raw/master/yql-feira-livre-sp.xml" AS feiras;

SELECT * FROM feiras WHERE zone = 'SUL' AND dayOfTheWeek = 'DOMINGO';

Veja o resultado no YQL Console.

Ou acesse o todo o código no Github.

Conclusão

Enfim, apesar de todos os problemas com as fontes de dados públicos, é possível extraí-los e convertê-los para uma representação melhor. Vimos também que serviços na Web como o Yahoo Query Language (YQL) permitem expor esses dados com uma API tão fácil quanto realizar uma simples query SQL, por meio de uma interface padronizada e única. E só com a exposição desses dados, num formato apropriado para que possamos programar com eles, teremos vários mashups gerando novos conhecimentos, sejam eles de interesse público ou não.

Nesta primeira parte desse artigo, cobrimos somente a Yahoo Query Language, na próxima parte iremos criar um mashup com o Yahoo Pipes que irá mapear todos os endereços de feiras livres da zona da cidade que o usuário escolher. Está curioso para saber o resultado? Não se aflija. E não perca a segunda parte na qual explicaremos como criamos esse mashup.

Hoje em dia, todo indivíduo envolvido com Web já consumiu alguma API HTTP, isso já é parte do dia a dia de qualquer desenvolvimento de aplicação web. Porém, nos últimos meses, começaram a aparecer alguns websites oferecendo APIs em outros protocolos, entre eles, o XMPP. Consumir uma API com esse protocolo é um pouco mais complicado que uma versão HTTP, mas o escopo e os benefícios obtidos são bem diferentes, como demonstraremos neste artigo.

XMPP em aplicações Web

Enquanto não temos suporte completo aos websockets do HTML5, que seria uma maneira de criar conexões TCP a partir do browser, a alternativa é usar a extensão BOSH do XMPP, que especifica como um cliente deve usar o XMPP via uma conexão HTTP. Vamos olhar com mais detalhe nos componentes envolvidos nesse tipo de conexão no diagrama abaixo, roubado diretamente da especificação da extensão:

    Servidor XMPP
        |
        |  [unwrapped data streams]
        |
    BOSH Connection Manager
        |
        |  [HTTP + <body/> wrapper]
        |
    Cliente (Browser)

• Entre o browser e o BOSH Connection Manager: por meio de long polling ou de qualquer outra técnica Comet, o browser envia requisições HTTP que respeitam a especificação BOSH (o HTTP + <body> wrapper no diagrama acima) para um gerenciador de conexões (BOSH connection manager), cuja responsabilidade é identificar a sessão XMPP e manter as informações dessa sessão.
• Entre o BOSH connection manager e o servidor XMPP: o connection manager deve criar e manter uma conexão TCP para cada sessão aberta com o servidor XMPP e é dessa forma que a tradução HTTP para TCP é feita.

Esse BOSH connection manager pode ser tanto um componente da sua infra quanto implementado dentro do próprio servidor XMPP. Você pode encontrar mais informações sobre esses conectores em http://xmpp.org/tech/bosh.shtml.

Strophejs

O Strophejs é uma biblioteca que implementa um cliente de XMPP em javascript, logo, pode ser utilizado em aplicações web. Entre as funcionalidades que essa biblioteca implementa, podemos citar:

• está em conformidade com a especificacão BOSH e o XMPP;
• é cross-browser;
• possui builders e usa jQuery, o que facilita o manuseio de XML;
• suporta vários métodos de autenticação;
• faz long polling e permite requisições HTTP cross-domain por meio de um componente flash;

Mashup de comparação em tempo real

O objetivo dessa aplicação é permitir que o usuário possa comparar dois assuntos (palavras-chave) de sua escolha em tempo real. Por exemplo, podemos disparar uma busca para comparar as linguagens Java e Ruby em tempo real.

Para que isto seja possível, iremos utilizar a API XMPP do Collecta, um site de busca em tempo real. A API do Collecta utiliza o modelo Publish-Subscribe para publicar os resultados de busca em tempo real para os usuários da API. Então vamos rever o cenário:

• Logo ao abrir o site a aplicação web connecta anonimamente no servidor XMPP por meio do Strophe;
• O usuário entra com uma busca;
• A aplicação web se inscreve em um nó pubsub (no caso, a busca);
• Ao confirmar a inscricão, a aplicação web está pronta para receber os eventos publicados;
• Ao receber um evento, a aplicação web faz um parse do XML e apresenta o resultado em HTML;
• O usuário pode agora comparar os resultados;

Todo o código deste exemplo está no Github caso queira acompanhar e executar o exemplo. Antes de detalharmos o que acontece em cada fluxo, as dependências dessa aplicação são as seguintes:

• jQuery: auxilia bastante no parsing de XML;
• flXHR.js: componente flash que permite requisições cross-domain, necessário para a aplicação se conectar num servidor XMPP em outro domínio;
• strophejs: sem ele não conseguimos usar o XMPP;
• dependências do strophejs: códigos para gerar md5, base64 e usar o componente flash;
• API key do Collecta: para usar a API do Collecta você precisa de uma chave.

Mesmo sendo todo implementado em HTML e Javascript, é importante servir essa página em um servidor web, para que o componente flash funcione.

Então vamos apresentar como se implementa cada fase do fluxo dessa aplicação (o foco será apenas no código javascript):

Ao abrir o site

A inicialização da conexão ao servidor XMPP já é feita logo que o usuário abre o site.

// config.js

var Config = {

    API_KEY: 'YOUR_COLLECTA_API_KEY',

    BOSH_SERVICE: 'http://collecta.com/xmpp-httpbind',

    HOST: "guest.collecta.com"

};

No arquivo de configuração acima, temos 3 itens importantes: a chave da API, o BOSH connection manager ao qual iremos conectar (tente abrir essa URL no seu browser) e o host (servidor XMPP) que queremos conectar. Temos um problema nesse ponto, a chave da API vai ser exposta aos usuários. Para o caso da API do Collecta, o único problema seria outro usuário consumir o rate limit, mas mesmo assim o time da Collecta deve procurar alternativas ainda, uma vez que a API é nova.

// real-time-comparison.js

// initiating a BOSH connection to create an anonymous connection to the Collecta XMPP server

connection = new Strophe.Connection(Config.BOSH_SERVICE);

connection.connect(Config.HOST, null, onConnect);

Graças ao strophejs, basta criar uma conexão como é feito acima, passando o serviço BOSH que deseja usar e depois chamar a função connect desse objeto. Os parâmetros passados são o host desejado, o usuário (que é null porque desejamos conectar anonimamente) e a referência à função que deve ser chamada (callback) ao receber algum status do processo de conexão.

// real-time-comparison.js

function onConnect(status)

{

    if (status == Strophe.Status.CONNECTING) {

    // ... outros status

    } else if (status == Strophe.Status.CONNECTED) {

        // adding one handler for each type of XMPP stanza

        connection.addHandler(onPresence, null, 'presence', null, null, null);

        connection.addHandler(onIq, null, 'iq', null, null, null);

        connection.addHandler(onMessage, null, 'message', null, null, null);

        console.log("Sending presence...");

        // app is available to use only after sending and receiving presence from the server

        connection.send($pres().tree());

    }

}

A função onConnect, ao receber o status informando que está conectado, irá criar os 3 handlers necessários para tratar o recebimento de cada um dos 3 stanzas existentes no XMPP. O primeiro parâmetro é o callback de referência e depois o tipo do stanza (leia a documentação do strophejs para saber quais são os outros parâmetros). Após a criação dos handlers, em toda conexão XMPP que é feita, o cliente deve enviar um stanza de presença para o servidor. Como estamos conectando anonimamente, neste caso, após o envio desse stanza, o servidor deve retornar um stanza de presença informando o Jabber ID do usuário anônimo.

// real-time-comparison.js

function onPresence(prs) {

    // in this case, presence got from the XMPP server means to activate UI and allow user to enter the 2 terms to compare

    console.log("Got presence!");

    anonymous_jid = $(prs).attr('to');

    // ... outras coisas

    return true;

}

Sendo assim, quando o servidor retorna a presença, nós simplesmente parseamos o xml com jQuery e pegamos o atributo “to”, que indica pra quem o servidor está mandando essa presença, ou seja, o usuário da aplicação. É importante retornar true no fim desse callback, pois sem ele o strophejs irá apagar esse handler. Com o return true, o handler não será apagado e deverá ser reutilizado no próximo stanza de presença que esse cliente receber.

O usuário entra com uma busca

Neste momento o usuário pode entrar com a busca no campo, ao clicar no botão “Go”, a seguinte função é chamada:

// real-time-comparison.js

function startComparison() {

    // creates 2 search subscriptions and send the request to Collecta XMPP API via Strophejs

    console.log("Subscribing to nodes: "+ terms[0] +" and "+ terms[1]);

    connection.send(Collecta.subscribeSearchStanza(terms[0]).tree());

    connection.send(Collecta.subscribeSearchStanza(terms[1]).tree());

}

Inscrição em um nó Pubsub de busca

Para evitar repetição de código, criamos uma pequena biblioteca chamada Collecta que monta os stanzas necessários para inscrever e desinscrever em um nó Pubsub, que representam as buscas. Nesta biblioteca também se encontra uma função para converter os resultados de busca de XML para JSON a fim de ser usado na hora de construir o HTML para o usuário.

// real-time-comparison.js

var Collecta = {

    subscribeSearchStanza: function(searchName) {

    // generate XML for a search subscription on Collecta XMPP API

    return $iq({type: 'set', from: anonymous_jid, to: 'search.collecta.com', id: searchName })

      .c('pubsub', {xmlns: 'http://jabber.org/protocol/pubsub'})

        .c('subscribe', {node: 'search', jid: anonymous_jid})

      .up().c('options')

        .c('x', {xmlns: 'jabber:x:data', type: 'submit'})

          .c('field', {"var": 'FORM_TYPE', type: 'hidden'})

            .c('value').t('http://jabber.org/protocol/pubsub#subscribe_options')

          .up().up().c('field', {"var": 'x-collecta#apikey'})

            .c('value').t(Config.API_KEY)

          .up().up().c('field', {"var": 'x-collecta#query'})

            .c('value').t(searchName);

 },

 // ...

O trecho de código acima apresenta como devemos criar um stanza utilizando o XML Builder implementado no strophejs. No caso dessa função, estamos criando um stanza do tipo iq para realizar a inscrição do nosso usuário (observador) em um nó PubSub. A construção desse stanza respeita a especificação PubSub do XMPP. Dê uma olhada na documentação da API do Collecta para ver como deve ser esse stanza que é enviado ao servidor.

Confirmação da inscrição

// real-time-comparison.js

function onIq(xml) {

    // in this case, the IQ stanzas handled are just subscription results

    xmlDom = $(xml);

    var iqId = xmlDom.attr('id');

    if (iqId == terms[0] || iqId == terms[1]) {

      if (xmlDom.find('subscription:first').attr('subscription') == 'subscribed') {

        console.log("Subscribed to "+iqId);

      }

    }

    return true;

}

Após enviar o stanza de inscrição, devemos esperar uma resposta do servidor. Quem processa essa resposta é o handler que tínhamos criado anteriormente. O procedimento é simples, com jQuery podemos navegar no DOM da resposta, se o id da resposta for o mesmo da busca realizada e o status da inscrição é “subscribed”, então o usuário está inscrito e agora só precisa aguardar os itens publicados.

Recebendo um evento publicado

// real-time-comparison.js

function onMessage(msg) {

    // messages stanzas are converted to JSON and then prepended to the correspondent panel in the UI

    var result = Collecta.processItem($(msg));

    for (var i=0; i < result.length; i++) {

       $('#term'+ result[i].term +"panel")

         .prepend("<p>["+result[i].category+"] - <a href=\""+result[i].url+"\" target=\"_blank\" title=\" Access "+terms[result[i].term]+" information\">"+result[i].title+"</a><br />..."+result[i].description+"...<br />Published in "+result[i].published+"</p>");

       };

    return true;

}

Os eventos publicados vêm em um stanza “message” e extendidos com a especificação PubSub. O único passo necessário e realizar o parse dessa resposta e convertê-lo para JSON, assim poderemos construir todo o HTML necessário para repassar esses resultados de busca para o usuário de forma mais fácil.

Após todo esse processo, o usuário já pode visualizar os resultados na página assim que eles forem sendo publicados no nó PubSub. Ufa!

Screenshot da comparação Ruby e Java

Quando há a necessidade de se obter resultados em tempo real na web, o antigo modelo de puxar a informação (pull) por meio de uma requisição HTTP já não é tão eficiente, pois perde-se tanto no desempenho do servidor, que terá uma alta carga devido às inúmeras requisições desnecessárias feitas, quanto na velocidade da informação, pois entre uma requisição e outra pode-se perder o efeito tempo real desejado.

Está crescendo cada vez mais o push como modelo para aplicações Web, na qual o servidor deve fornecer a informação para os clientes web logo que ela for publicada. Juntamente com o modelo de push, o modelo Publish-Subscribe também está se provando efetivo, uma vez que não é só implementado em XMPP, mas também em Webhooks, Pubsubhubbub, entre outros.

O diferencial do XMPP neste caso é a especificação da extensão Publish-Subscribe, que é bastante detalhada e cobre vários fluxos que podem existir no modelo PubSub, além é claro dos vários servidores que já implementam este módulo. Vale a pena experimentar.

Ele muitas vezes é lembrado apenas como um protocolo para criar chats e restrito apenas à plataforma cliente, mas não nos prendamos a esse pensamento simplista, existe muito mais poder que pode ser extraído das mensagens trafegadas por essa camada de aplicação.

Segundo os autores do protocolo, o XMPP é uma tecnologia aberta para comunicação em tempo real que permite a criação de vários tipos de aplicações, tais como instanting messaging, presença, chats multi-usuários, chamadas de voz e vídeo, colaboração, middleware, content syndication e qualquer transmissão de dados via XML. Talvez a definição mais curta possível seja: é um protocolo para a criação de middlewares orientado a mensagens. E canais de troca de mensagens existem em qualquer sistema distribuído, e acredite, XMPP pode ser usado em cada um deles, desde que, é claro, isso traga benefícios ao sistema ou ao desenvovimento.

Do que é feito o XMPP?

O protocolo XMPP situa-se na camada de aplicação e é comumente transportado por conexões TCP. Ele constitui-se de XML e possui apenas 3 unidades básicas de transporte, chamados stanzas: <presence>, <message> e <iq>. Iremos apresentar brevemente cada stanza, mas se quiser mais detalhes acesse o RFC do XMPP:

Presence

<presence from="cipriani@talleye.com/casa">

    <status>Ouvindo música...</status>

</presence>

O stanza de presença tem a funcionalidade de notificar servidores e a lista de contatos sobre o status de um usuário na rede XMPP. Essa é uma das grandes vantagens do XMPP em relação à outros protocolos de mensageria, pois a propagação de presença faz parte da especificação e portanto deve ser implementado por clientes e servidores por padrão. No exemplo acima, o usuário cipriani@talleye.com/casa está notificando a rede XMPP de que ele está online, e mais, ouvindo música.

Outro detalhe importante é a forma de endereçamento dos stanzas, ou melhor, de que forma você identifica unicamente um usuário na rede XMPP. No exemplo, o usuário é o cipriani@talleye.com/casa. “cipriani” é o nome do usuário, “talleye.com” é o host ao qual esse usuário pertence e a palavra “casa” é o recurso, utiliza-se o recurso para permitir que um mesmo usuário esteja conectado ao mesmo tempo em vários clientes diferentes (o usuário poderia ter um recurso de nome “escritório” por exemplo). Esses três pedaços constituem o Jabberd ID, ou JID, e é utilizado em todos os tipos de stanzas.

Message

<message to="pedro@shorteye.com/escitorio"

      from="cipriani@talleye.com/casa"

      type="chat" >

    <body>Cadê você?</body>

</message>

No stanza acima, um usuário envia uma mensagem para outro, do tipo “chat” com o conteúdo (body) “Cadê você”. Os stanza de mensagem é enviado e o cliente não deve esperar nenhuma resposta do servidor informando que a entrega foi feita, ele apenas envia para o usuário destino ou armazena caso o usuário esteja offline.

IQ (Info Query)

<iq type="set" id="an_id"

      from="cipriani@talleye.com/casa"

      to="talleye.com">

    <query xmlns="jabber:iq:roster"/>

</iq>

Diferente do stanza message, cada stanza iq enviado ao servidor deve obter uma resposta, por isso existe o atributo type, que pode ter valores set ou get, e como resposta o usuário recebe um outro iq de tipo result ou error, dependendo do status.

No caso do stanza acima, estamos requisitando ao servidor XMPP a lista de contatos de um usuário. E a tag query dentro do iq nos remete a uma outra funcionalidade do protocolo XMPP, talvez a mais importante, que são as extensões!

Extensões

O significado da sigla XML é Extensible Markup Language. O XMPP usa XML para implementar o protocolo. Opa, peraí, quer dizer então que eu posso extender o XMPP? Sim!

O desenvolvedor é livre para incluir qualquer XML dentro ou fora dos stanzas, desde que seu cliente e servidor XMPP conheçam o seu significado. Para que o protocolo não virasse bagunça e todos pudessem usufruir de servidores e bibliotecas que implementam extensões, contruiu-se uma comunidade para especificar e publicar as especificações.

Após 10 anos, há um número alto de exensões, por exemplo, algumas disponíveis são:

• Service Discovery: extensão para que um usuário possa acessar quais serviços um servidor XMPP oferece.
• Multi-User Chat: extensão para criar salas de bate-papo multi usuários.
• Jingle: extensão que permite chamadas via vídeo.
• Bidirectional-streams Over Synchronous HTTP (BOSH): essa extensão permite um cliente HTTP conectar em um servidor XMPP por meio de um connection manager, cuja responsabilidade é converter uma sessão XMPP de HTTP para TCP.
• Publish-Subscribe (PubSub): essa extensão implementa o modelo Publicador/Observador, no qual um observador pode assinar um canal do publicador. E cada vez que um item for publicado nesse canal, o observador irá recebê-lo.
• Tem muito mais de onde essas vieram, sugiro dar uma olhada.

Por quê XMPP?

Quais as razões que faria com que eu utilizasse o XMPP como protocolo ao invés de qualquer outra implementação, como AMQP ou até um protocolo mais simples escrito por mim mesmo?

Como tudo na computação, não tem nenhuma tecnologia que é boa para todos os casos, por isso a melhor resposta é aquela de sempre: depende! Primeiro vamos dar uma olhada em alguns motivos que favorecem o uso do XMPP:

Por ter uma comunidade forte o XMPP é um protocolo sólido, vários fluxos já foram pensados, testados e é um protocolo ativo, que se adapta às necessidades dos seus usuários. Além disso ele é apoiado por bibliotecas e servidores que implementam e oferecem as principais extensões, é descentralizado (e por isso, escalável), seguro e extensível.

Por outro lado, dependendo da complexidade da aplicação, o XMPP pode ser muito burocrático e um protocolo mais simples é bem mais efetivo. O mesmo acontece se você tentar utilizar uma extensão XMPP quando na verdade já existe algum outro protocolo especialista em um modelo de mensagem.

Por experiência própria, já iniciei um sistema que nem imaginava utilizar XMPP, mas à medida que a arquitetura foi crescendo ele foi se tornando um protocolo interessante e por fim se transformou no principal componente. Enfim, o importante é conhecer suas opções, estudar e experimentar. Mas sempre tenha na sua lista o XMPP e suas extensões, pois muito do que o arquiteto de software precisa criar já está escrito em algumas de suas especificações.

Valeu, Einstein!

Rá!

Piadas infames à parte, divirtam-se e colaborem.