Google Data API

fevereiro 21, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

I’m currently using Google Data API at work. This API offers RESTful interfaces for several Google services, such as Calendar, Picasa, You Tube, Blogger, Google Documents, among others. There are also client libraries for Java, C# and Python, but these are actually tools to facilitate, rather than new interfaces. All client libraries access the RESTful interfaces, so by all acounts the API is RESTful.

What I’d like to comment is how easy it was for me the to get up to speed with the API. There are several pages explaining the API’s features, the URIs, their use of HTTP method, return types, etc. Their design is pretty much compliant to all REST best practices (although they do use some query string parameters ocasionally). Being very familiar with this kind of web services, most of what I did was looking and saying: “Ok , this is how i expected it to be”. And after less than one hour I was ready to begin using the API properly.

Worth noting is that there were no “Interface Document” to look at. Not anything similar to WSDL or any other IDL. What was there was just a simple and RESTful API that was pretty easy to use after you knew what the resources were and which operations they support. Several pages describing their protocol and the XML entities they use were enough for me to know how I was supposed to integrate with a reasonable amount of their services.

I don’t even want of to think of how would it be if they had WS-*. Just to read the WSDL documents would take me more time than to read all their RESTful documentation. There would be a lot of operations and messages described in their WSDLs, and it’d be a massive reading to get the grasp of the API.

Fortunately Google (the most powerful web company) is embracing a RESTful design and it should probably take many other companies with it. They’re also supporting the use of Atom and Atom Publishing Protocol, so many nice things should keep coming. Apache Abdera is already integrating Google Feed Server code, and hopefully we’ll be able to use Abdera for most of Google’s services.

Very very nice! By the way, I took a good look in the source code of Google Data API and it’s very well implemented. They have a very interesting approach to manipulate feeds and entries. It makes it very easy to model a lot of stuff using just feeds and entries. It was an inspiring code inspection and I’m thankful Google also embraces open source 🙂 These guys are good!


Grow as needed + YAGNI

dezembro 25, 2007

Atenção, este blog foi migrado para: http://brunopereira.org

No meu tempo de experiência com Java EE já pude aprender e constatar bastante coisa. Um fenômeno que se repete com freqüência é a escolha de servidores e componentes que contêm muito mais do que se necessita para a resolução de um problema específico.Um exemplo claro disso é em aplicações que não precisariam de absolutamente nada que o Tomcat não ofereça, mas a escolha padrão acaba sendo um servidor de aplicações “mais parrudo”, como JBoss, WebSphere ou Weblogic. O curioso é que estes últimos servidores de aplicação suportam uma quantidade bem mais ampla de especificações e oferecem bem mais recursos, mas o que eles realmente oferecem de diferencial não é o que está nas especificações, na maioria dos casos.

Muitas vezes o diferencial destes produtos está em funcionalidades nos quais eles excedem as especificações e oferecem facilidades que não são obrigatórias. O fato de oferecer estas funcionalidades extras é muito bom, pois isto traz mais qualidade aos clientes, e isto possivelmente melhora os processos internos do cliente. Apesar disso, é comum vermos escolhas de tecnologia serem feitas porque a opção A oferece muito mais recursos do que a opção B, sendo que na prática as opções oferecidas pela opção B serão plenamente suficientes para atender a todos os “problemas reais” que virão a surgir. Isto quer dizer que é comum a opção A ser escolhida em vez de B sem que se saiba quais recursos de A serão úteis de verdade, mas pela percepção que “A oferece mais do que B”.

Talvez a justificativa para este comportamento seja escolher uma opção que “possua todos os recursos que necessitaremos”. Consigo entender isso. Porém, isto traz o caso comum de usar uma bazuca para matar uma mosca. Sim, com a poluição e evolução das espécies, podemos no futuro encontrar super moscas mutantes do tamanho de um helicóptero, e neste caso espero que você esteja com sua poderosa bazuca para matar essa mosca monstruosa! 🙂

Entretanto, para as moscas que eu costumo encontrar, um mata-moscas de plástico resolve o problema. Além disso, eu sei usar bem um mata-moscas de plástico, e foi bem mais fácil de aprender a usá-lo do que aprender a usar uma bazuca. Por oferecer bem menos e ser bem mais simples, o modo de operação do mata-moscas de plástico é algo que uma criança consegue aprender. Já para utilizar a poderosa bazuca matadora de moscas mutantes, é bom ler direitinho os manuais de utilização e se possível fazer o curso prático para fixar bem os conceitos. Afinal de contas você não quer correr o risco de se deparar com uma mosca mutante e não saber usar a bazuca né?

Da mesma forma que as moscas, as aplicações corporativas possuem este tipo de fenômeno. Antes de conhecer as necessidades reais da aplicação, já se definiu o uso do Weblogic com Oracle e possivelmente a configuração de um cluster de alta disponibilidade. Talvez fosse uma aplicação pequena ou média que o Tomcat + Derby ou Postgres ou Mysql pudesse dar conta sem problemas.

Eu venho estudando muito sobre web services nos últimos meses. Também nesta área isto ocorre bastante. Sem conhecer bem as necessidades que se quer resolver, já foi escolhida a pilha de componentes que “oferece tudo de web services”.

Este fenômeno é global, ocorre no mundo todo. Opiniões interessantes sobre isso foram dadas por Bill de hÓra e Rod Johnson. Uma abordagem que pode ser tomada é tomar as decisões de tecnologia baseando-se nos requisitos já inicialmente definidos. Pegar os requisitos funcionais e não-funcionais iniciais da aplicação e então decidir as tecnologias a se utilizar parece uma boa escolha. Desta forma, você possivelmente fará boas escolhas sem trazer desde o começo uma complexidade e custo que possivelmente nunca seriam necessários.

Claro, existem casos em que realmente se utilizará extensamente os recursos avançados do Weblogic e do Oracle, e eles são de fato necessários. Da mesma forma, podem existir web services com altos requisitos de segurança e confiabilidade que te façam depender de recursos do stack WS-*. Se este for o caso, escolha mesmo as opções com mais recursos e utilize tudo que precisar para atender aos requisitos críticos que lhe forem apresentados. Porém, saiba que estes casos são a minoria dentre as aplicações corporativas existentes mundialmente.

Se o seu problema for algo mais comum, escolha produtos e componentes que resolvam bem os problemas apresentados, e se algum dia eles deixarem de atender às necessidades, pondere novamente as suas escolhas. Isto sugere o “Grow as needed” do título. Cresça a sua estrutura conforme necessário, não compre inicialmente uma bazuca se ainda não existem moscas mutantes. E se os seus problemas não mostram claramente a necessidade da bazuca, aí provavelmente surge a sigla do título: YAGNI (You aren’t gonna need it)!

Antes de escolher as opções “mais ricas e robustas” disponíveis, estude se opções mais simples são capazes de resolver os seus problemas, pois se isto for o caso, você provavelmente terá uma configuração mais simples e mais barata e cheia de pessoas capazes de manipulá-la. Isto é melhor do que depender vitalmente de algum fornecedor e precisar contratar o super especialista que é um dos poucos no mundo capazes de resolver seus pepinos.

E claro, se suas decisões puderem ser de componentes open source, você não pagará nada de licença de software e terá uma grande variedade de profissionais disponíveis para te oferecer serviços 🙂


@dvogado.com aprovado no java.net!

novembro 28, 2007

Atenção, este blog foi migrado para: http://brunopereira.org

Caros amigos, já comentei aqui anteriormente que no meu tempo vago desenvolvo um software para advogados. Este projeto é open source e está em desenvolvimento, ainda não tendo nenhuma release.Algumas semanas atrás eu cadastrei o projeto no java.net, e hoje recebi o e-mail me informando que ele foi aprovado lá! O projeto está oficialmente incubado no java.net. A home do projeto lá é https://advogadocom.dev.java.net/

Os detalhes do projeto podem ser vistos na página do java.net, mas a arquiteturá básica terá Apache Tomcat 6.0.x + Apache Derby 10.x + Java RE 6 + Apache Wicket como framework web.

Quando tiver mais novidades do projeto, voltarei a postar aqui! 🙂


A fascinação por sequences de BD x UUIDs

novembro 22, 2007

Atenção, este blog foi migrado para: http://brunopereira.org

Uns tempos atrás eu pude constatar um fenômeno curioso. Existem pessoas fascinadas, apaixonadas por sequences de bancos de dados!! Ok,vou contextualizar.Sequences de bancos de dados são muitos boas para fazer o que elas foram inventadas para fazer: gerar seqüências numéricas inteiras. Claro, estes valores numéricos seqüenciais não se repetirão, então eles também PODEM ser utilizados como identificadores únicos de tabelas de bancos de dados (chaves primárias).

A questão é: chaves primárias oficialmente são identificadores únicos de registros no banco de dados. Não há nada especificado quanto a eles serem numéricos e muito menos seqüenciais.

Algumas pessoas argumentam que o fato de os identificadores serem seqüenciais ajuda a saber a ordem de criação dos registros no servidor. Isso é verdade, mas eu considero isto uma meta-informação sobre o registro em questão. Esta meta-informação não precisa estar gravada na chave primária. Se esta meta-informação sobre a ordem de criação no banco de dados é relevante para quem precisar analisar os dados, porque não criar uma coluna registrando a data de criação, outra com data da última modificação, etc? Impossível ser mais preciso quanto ao momento de criação e de alteração do que gravar o instante em que as coisas foram feitas com precisão de milisegundos.

Esta contextualização toda foi para chegar no ponto em que eu queria. Você conhece UUIDs? Desde que eu conheci UUIDs, não soube de nada mais indicado para ser utilizado como identificadores únicos de entidades, e em decorrência, como chaves primárias. Os UUIDs são valores numéricos de 128 bits, que possuem uma representação textual, da forma 9c7b8ee2-6f22-4dad-bdec-1266bb533ac6.

Já ouvi algumas vezes a frase de que o IPv6 possui quantidade suficiente de IPs para endereçar cada grão de areia do mundo. Pois é, o IPv6 e o UUID possuem 128 bits, então se você tem identificadores suficientes para cada grão de areia do mundo, acho que dá pra usar UUIDs com aquela sua tabelinha, não dá não? 😉

Bom, agora preciso explicar porque eu acho melhor usar UUIDs como chaves primárias do que sequences de BD. Pra começo de conversa, o acesso ao sequence para obter um ID é muuuuuito mais lento que a geração de um UUID. Eu não tinha a exata noção do peso de acessar uma sequence, mas o Silvano descobriu junto com o pessoal de BD da Globo que em boa parte dos casos a query na sequence para obter um ID a ser colocado em um INSERT é mais lenta do que o próprio INSERT. Além disso, para gerar um UUID a sua própria aplicação consegue gerar. Nada de comunicação remota com o banco de dados.

Além de ser muito mais eficiente em termos de performance, existe a questão da migração de dados. Sempre que é necessário migrar bases de dados corporativos, uma das maiores dores de cabeça é gerenciar os conflitos de IDs gerados através de sequences. Além disso, em muitos casos o problema surge bem antes da necessidade de se migrar bancos de dados. Onde existe o conceito de sincronização de dados o uso de UUIDs faz muito mais sentido do que usar sequences. Sequences são muitas vezes impeditivos na verdade. Darei um exemplo.

No meu projeto do software para advogados, eu quero permitir que cada advogado use a aplicação em suas máquinas individuais. Suponha que o advogado Fulano cadastrou alguns processos, clientes, reuniões, etc em sua máquina. Suponha também que o sócio dele, o advogado Sicrano também fez alguns cadastros de processos, clientes, etc em sua máquina. Suponha agora que os 2 gostariam de compartilhar seus dados. Se as chaves primárias fossem sequences, isso significaria gravar na máquina do Sicrano os processos com IDs 1, 2, 3, 4… que foram cadastrados na máquina do Fulano e gravar na máquina do Fulano os processos com IDs 1, 2, 3, 4… cadastrados na máquina do Sicrano. Opa, não demorou muito pra ter conflito não é?? Agora, se os IDs fossem algo como 9c7b8ee2-6f22-4dad-bdec-1266bb533ac6, a sincronização seria moleza não é mesmo?

Esta questão da sincronização de dados é necessária para muitas aplicações. O Siebel (CRM comprado pela Oracle) possuía o conceito de usuários remotos e usuários normais. Os usuários normais faria tudo diretamente no servidor de produção. Os usuários remotos fariam o seu trabalho em um laptop se deslocando diariamente em seu trabalho e então sincronizariam suas atividades 1, 2 vezes por dia tipicamente. Impossível fazer isso com sequences. O Siebel usava chaves alfanuméricas geradas com um algoritmo próprio que eu não conheço, mas funcionava também. O UUID resolve facilmente este problema, e está disponível para qualquer um utilizar em boa parte das linguagens de programação.

Assim, o que quero concluir é: chaves primárias são identificadores únicos e pronto!! Porque as chaves primárias têm que ser números inteiros, seqüênciais e sem saltos entre eles?? A resposta é: elas não precisam!! Para ter meta-informações sobre os registros, defina as meta-informações que você quer e aborde isto explicitamente.

Bom, mais uma vez, não espero convencer ninguém, só dei a minha humilde opinião. 😉


REST vs SOAP

novembro 21, 2007

Atenção, este blog foi migrado para: http://brunopereira.org

O Dan Diephouse, fundador do XFire e atualmente trabalhando no ESB do Mule postou em seu blog uma opinião que vem bastante de encontro ao que eu penso, e que é contrária à febre atual de REST, que possui defensores que o julgam uma melhor opção por ser mais simples que SOAP.Eu ainda vou postar futuramente a minha opinião com bastante detalhes sobre o assunto, mas um ponto que eu acho muito importante é: WS-* is complex. REST is complex. It’s all complex. Complexity is not the issue. The real issues are things like utility, consistency, accessibility, etc.

Na minha humilde opinião, raríssimas são as pessoas no Brasil que já tiveram contato prolongado com SOAP e REST e que de fato vivenciaram na pele as conseqüências de escolhas de tecnologias com SOA após um uso contínuo. Portanto, acho um tanto precipitado sair emitindo opiniões conclusivas sobre qual opção é melhor simplesmente por ver que SOAP é mais “verbose” do que REST.

Sim, SOAP é um protocolo dentro de outro (99,9% das vezes dentro de HTTP) e REST é apenas HTTP. Isto já mostra por si só que SOAP tem um overhead de protocolo maior. Mas este fator é apenas um bem pequeno ítem nas considerações totais entre as 2 formas de implementar web services.

Assim, ouso dizer: quem justifica a escolha de REST em vez de SOAP por dizer que REST é mais leve e simples não sabe do que está falando. Todos os caras que já trabalharam de verdade com as 2 opções e viram o domínio do problema amadurecer têm opiniões muito mais pragmáticas e argumentos muito mais profundos do que estes, e chegaram nestas opiniões após ANOS de experiência intensa com o problema.

A propósito, já implementei aplicações tanto com SOAP, como com REST, e quanto mais eu estudo e aprendo sobre o assunto, mais difícil fica dar uma opinião conclusiva sobre o assunto. Ainda estamos engatinhando em SOA, principalmente no Brasil. Se quiserem conferir parte do que venho lendo sobre isto, venham aqui.