Bruno Pereira

Nos últimos meses trabalhei em uma boa diversidade de projetos, no trabalho, em projetos pessoais e artigos. Sem motivo nenhum especial, lidei nestes projetos com uma boa variedade de servidores de bancos de dados.

A maioria das coisas que faço no trabalho envolvem o Oracle, mas nos projetos pessoais utilizei o SQL Server, Postgresql, MySql e o Derby. 5 produtos diferentes, cada um com suas particularidades. Este convívio com diferentes bancos de dados me permitiu uma boa análise do momento em que já estamos em relação ao uso dos mesmos.

Na prática, basicamente o que mudava para mim de um BD para o outro era saber qual ferramenta de administração que eu deveria utilizar e qual driver jdbc precisaria baixar. Nos casos em que a camada de persistência era com jdbc diretamente (em vez de mapeamento objeto-relacional), eu precisava também prestar um pouco de atenção com pequenas diferenças na sintaxe SQL de cada um.

Algo que me chamou a atenção quando parei para pensar sobre isso foi que para a maioria dos projetos, qualquer servidor de banco de dados que eu utilizasse me atenderia sem problemas. Em termos de funcionalidades, o que eu preciso em um banco de dados não é nada sofisticado. Eu gosto de tratar do SGBD como um repositório confiável e eficiente para persistência de dados. Prefiro deixar toda a inteligência da aplicação fora do BD. O que eu espero de um bom servidor de BD é que ele mantenha os dados íntegros, ofereça recursos de restrições de integridade, índices, sub-queries e mais algumas funcionalidades nada extraordinárias.

Como falei, não gosto de colocar inteligência no banco de dados, então descarto o uso de stored procedures, triggers e coisas do gênero sempre que possível. A maioria dos SGBDs atuais suporta todos estes recursos que mencionei. Para a maioria das aplicações que desenvolvemos, o Oracle, Sql Server, DB2, Postgres ou MySql sem dúvida servem tranqüilamente. O conjunto de aplicações que tem acessos suficientes para derrubar qualquer um destes servidores é muito pequeno. Se na maioria dos casos qualquer SGBD serve, será que já podemos considerar os bancos de dados como commodities?

É claro que existem aplicações nas quais as exigências sobre o banco de dados são muito críticas. Alguns sistemas usam intensamente o servidor de banco de dados e possuem tabelas com milhões de registros que precisam de uma indexação muito eficiente. Embora talvez seja possível usar perfeitamente o Postgres e o MySql nestes casos, eu tomaria uma postura mais conservadora e só adotaria um dos 2 após diversos testes de carga sobre a aplicação usando eles.

Da mesma forma que existem aplicações que precisam de um servidor de banco de dados extremamente robusto, existem aplicações nas quais a praticidade de uso é o requisito mais importante. Temos por exemplo casos em que utilizar o Derby ou HSQLDB no modo embedded podem ser muito convenientes. É claro que o Derby e o HSQLDB não agüentam a mesma carga que os outros servidores mencionados. Todavia, a capacidade de empacotar o banco de dados dentro da sua aplicação pode ser muito conveniente, e nestes casos o Derby e o HSQLDB não poderiam ser substituídos por nenhum outro desta lista.

Nos casos em que os requisitos de banco de dados não são convencionais, algumas opções podem se mostrar muito mais adequadas do que outras. Entretanto, na maioria das aplicações, a troca de um produto pelo outro não fará muita diferença. Os recursos que realmente precisamos a maior parte do tempo estão disponíveis na maioria dos produtos.

A forte competição imposta pelos BDs open source fez com que os SGBDs comerciais passassem a oferecer versões gratuitas de seus produtos, com algumas limitações de uso. Para enfrentar este novo desafio, o Postgresql e o Mysql foram investindo cada vez mais esforço em seus produtos e hoje já têm uma ampla gama de recursos que antigamente só víamos em produtos comerciais. Com esta evolução do mercado, temos um largo leque de opções para escolher e estimo que em 90% dos casos, qualquer uma das opções atenderá plenamente.

Na minha opinião, isto já é suficiente para classificar os bancos de dados como commodities, na maioria dos casos. Já podemos ir na farmácia e pedir pelo genérico

Hoje assisti a um Tech Talk bem interessante na Globo, sobre mod_rewrite. Além de funcionalidades interessantes deste módulo do Apache, as discussões na apresentação me trouxeram vários questionamentos de como incluir de forma mais ativa o Apache em uma arquitetura RESTFul.

Eu já utilizei bastante o Apache na remota época em que eu desenvolvia algumas coisas em Php. Na verdade não fazia nada de muito sofisticado, mas tinha boa familiaridade com os módulos, com a configuração, essas coisas. Depois que foquei mais no uso de servidores de aplicação Java, deixei o Apache em segundo plano. Praticamente só vinha usando o Apache para servir conteúdo estático, e claro, nele também ficam configurados os conectores para comunicação com os servidores de aplicação.

Como tenho trabalhado bastante com web services REST, venho tentando explorar ao máximo os recursos do HTTP para elaborar protocolos de comunicação concisos e intuitivos. Neste sentido, o Apache oferece recursos muito interessantes. Por exemplo, quando utilizamos URIs no formato /usuario/123456/item/25 para representar um determinado item de um determinado usuário, a resposta a esta requisição é cacheável pelo Apache. Entretanto, ao utilizar URIs neste formato você precisa definir uma forma de fazer o parsing da URI para pegar os parâmetros relevantes.

No meu artigo de REST da Java Magazine de Abril eu usei o StringTokenizer do JDK para fazer a quebra da URI e pegar os valores que me interessavam. A JSR-311 define uma forma bem interessante de fazer isso com annotations também. E hoje fui descobrir que o mod_rewrite também pode fazer facilmente a quebra de URIs neste formato em URIs com parâmetros em query string por exemplo.

Uma utilização inteligente do cache do servidor web e de módulos de proxy também pode tornar a arquitetura da aplicação bem eficiente e reduzir bastante a carga sobre os servidores de aplicação. Se eu posso utilizar diretamente o cache do Apache para várias URIs, não vale a pena deixar as requisições chegarem ao container de servlets, mesmo que ele responda também com dados em cache.

Vendo o poder e a facilidade de uso de alguns módulos do Apache, me sinto obrigado a ter total familiaridade com ele novamente. Aos poucos irei estudando e integrando os módulos do Apache à arquitetura das minhas aplicações REST, pois isto pode trazer um belo ganho de performance e escalabilidade. Afinal de contas, quem quer explorar a fundo os recursos do HTTP não pode abrir mão de explorar a fundo um servidor tão confiável e maduro como o Apache, não é mesmo?

OBS: uns anos atrás eu dizia pra mim mesmo que o dia que eu conhecesse pelo menos vagamente metade dos projetos na home da Apache Software Foundation eu já teria uma boa bagagem. Hoje em dia já conheço mais da metade do projetos da home, e admiro cada vez mais esta fundação. O mundo open source não chegaria aos pés do que é hoje sem a existência da ASF. Um belo exemplo de qualidade em software!

Caros amigos, nos próximos dias chega às bancas a edição 55 da Java Magazine. Nesta edição sai um artigo meu entitulado “Web services WS-*“.

Este artigo é uma continuação do artigo da edição 54, na qual fiz uma análise dos web services REST e web services WS-*. Na edição 54, o foco era mais teórico, discutindo várias questões relevantes da implementação de web services nas 2 linhas de desenvolvimento.

Neste artigo, o objetivo é partir de um problema real de arquitetura orientada a serviços, e então realizar a modelagem e implementação utilizando a pilha WS-*. O exemplo adotado para contextualizar o problema é o processo de leilão do Mercado Livre, mas num contexto de leilão com apenas 1 usuário adquirindo um determinado item. O desenvolvimento foi feito utilizando o Apache Axis 2, uma das opções mais populares para o desenvolvimento deste nicho em Java.

Na edição 56, esta série será complementada com outro artigo prático, que utiliza a abordagem REST para resolver o mesmo problema proposto para esta edição. O objetivo com estes 2 artigos práticos é utilizar um mesmo exemplo que seja de fácil visualização por parte dos leitores e então descrever os detalhes principais do desenvolvimento de web services utilizando a abordagem WS-* e a abordagem REST.

Espero que os leitores gostem destes artigos e torço para que eles possam contribuir com o entendimento do desenvolvimento de web services, e mais especificamente, a implementação em Java. Ao longo do ano escreverei mais artigos nesta área, então se você tiver interesse no assunto, certamente recomendo acompanhar as edições futuras da revista

Eu nunca havia falado sobre política aqui no blog e definitivamente não pretendo fazer isso com freqüência, mas essa semana recebi uma notícia digna de nota. O deputado federal Fernando Gabeira será candidato a prefeito do Rio de Janeiro.

Depois de inúmeras gestões corruptas e pouco eficientes tanto na prefeitura como no governo do estado, este anúncio traz a esperança de tempos melhores para nossa cidade. O Gabeira é um dos raríssimos políticos no Brasil nos quais eu confio, de quem eu sei que posso esperar honestidade e decência.

Desde que eu comecei a votar, nenhuma das eleições para o Rio de Janeiro me trazia nenhum ânimo, pois todas as opções disponíveis significavam “mais do mesmo”ou “pior do que já está”. E após 2 décadas extremamente negativas, nas quais a cidade e o estado foram sendo destruídos, existe finalmente um sopro de esperança. Após inúmeras obras super faturadas, descaso completo com os serviços públicos e corrupção da pesada, eu cheguei num ponto de insatisfação com minha terra natal que me fez decidir me mudar aqui. Vivemos atualmente num imenso favelão, um verdadeiro caldeirão dos diabos em que somos cozidos e torcemos para não sermos devorados pela violência assustadora que tomou conta da cidade.

O anúncio da candidatura do Gabeira me deixou bastante esperançoso, e torço demais para que finalmente tenhamos uma gestão que busque melhorar as condições da população carioca. Ainda não conheço os outros candidatos, mas sei que certamente veremos figurinhas manjadas tentando prosseguir com o estado precário em que nos encontramos. Deixo aqui meus votos para o Gabeira tenha forças para suportar toda a nojeira que deve ser esse jogo político aqui no estado e emerja vitorioso no final do ano. O Rio de Janeiro precisa demais de você, e como qualquer carioca que quer o bem da cidade, te desejo todo o sucesso nesta árdua empreitada!

Hoje eu tive que criar algumas requisições HTTP através de um proxy, numa integração que estou implementando. Minha aplicação precisa enviar solicitações HTTP a um servidor remoto, passando por um proxy, e eu uso o Commons HttpClient para montar estas requisições.

Como achei a documentação disso bem fraquinha no site do projeto, resolvi postar aqui um exemplo de código para facilitar quem possa precisar (e a mim mesmo no futuro). Este exemplo é um método de teste junit bem simples que monta uma requisição RESTful de cadastro de um novo usuário, especificando as configurações do proxy na API. Utilizei o XStream para fazer as manipulações XML. Segue o exemplo:

public void testCriacao() throws HttpException, IOException{
Usuario novoUsuario = new Usuario();
novoUsuario.setLogin("fulano");
novoUsuario.setSenha("123456");
novoUsuario.setNome("Fulano");
novoUsuario.setSobrenome("da Silva");
novoUsuario.setStatusConta(1);
novoUsuario.setTamanhoMailBox(6144);

HttpClient client = new HttpClient();
//servidor remoto que iremos acessar
HostConfiguration hostConfiguration = new HostConfiguration();
hostConfiguration.setHost("www.domain.com", 8080);
// proxy pelo qual precisamos passar
ProxyHost proxy = new ProxyHost("10.10.10.10", 9090);
hostConfiguration.setProxyHost(proxy);
client.setHostConfiguration(hostConfiguration);

PostMethod method = new PostMethod("http://www.domain.com:8080/MailIntegration/usuario/");
XStream xstream = new XStream();
xstream.alias("usuario", Usuario.class);
String usuarioXml = xstream.toXML(novoUsuario);
StringRequestEntity requestEntity = new StringRequestEntity(usuarioXml, "text/xml", "UTF-8");
method.setRequestEntity(requestEntity);
int statusCode = client.executeMethod(method);
assertEquals(201, statusCode);
Usuario usuarioCadastrado = (Usuario)xstream.fromXML(method.getResponseBodyAsStream());


Após algumas conversas recentemente aqui na Globo, algumas pessoas se mostraram interessadas no RESTFox, pois facilitaria bastante os testes de nossas interfaces REST.

Após alguma pesquisa e alguns testes, descobri que o Firefox suporta de fato os métodos HTTP PUT e HTTP DELETE. Eles não podem ser usados em formulários, entretanto. Se você tentar utilizar algum método diferente de GET e POST em um formulário, o browser converte a requisição para GET.

Já o XmlHttpRequest suporta estes métodos, e o RESTFox certamente faria uso disto, e não de um formulário. Sabendo que a idéia é válida, tentarei em breve começar o desenvolvimento do plugin, e quando já tver algo concreto coloco aqui.

Recently I’ve had several conversations regarding the Atom Syndication Format. This format is gaining more and more adopters and several big players in the industry are using it. Just to name the big boys, Google AND Microsoft are using it to implement RESTful APIs. When was the last time you heard Google and Microsoft agreed on something? This should hint that Atom is indeed a nice thing happening in our field.

Web services using the Atom format for data exchange encapsulate information using Atom’s standard elements and also define some extension points where needed. Some very useful elements are present in the specification. There are standard ways of publishing individual entries and collections, pagination support, links between resources, among other things useful for RESTful web services.

Depending on your domain model, the amount of data you would put in Atom extension points varies a lot. Some domains such as Google Apps can produce a RESTful model that uses a lot of Atom’s standard elements without needing to define too much extension points. However, if you use Atom to exchange billing information between ISP applications, you’ll probably have to define a lot of extension points. I’m saying this to show that some domains match much better to Atom structures than others.

While talking to Silvano (a very clever working mate of mine) a couple of weeks ago, he asked me if encapsulating everything inside Atom elements was not the same as encapsulating everything inside SOAP. This is a very very good question.

When you’re choosing a format for you data exchange in web services, it’s very important to analyse what you gain and what you lose by picking any given format.

For example, a good rule of thumb about SOAP services is: “WS-* is just overhead unless you have something meaningful in your SOAP Headers” (quoting Sanjiva Weerawarana at ApacheCon 2007).

Atom was designed in a RESTful manner by a very talented group of professionals. Many applications are making use of it to exchange data, and the adoption is growing fast. Could it be a silver bullet then?

That’s where I shall leave my observations. If you consider my example of billing information, you’ll see that most of the data there doesn’t mesh well with Atom’s standard elements. Thus, we’d need to define a lot of extension points, and wouldn’t make much use of Atom’s resources. Putting billing data inside Atom entries would represent an overhead without giving us much in return. In this case, I’d rather use my own XMLs directly over HTTP.

Am I saying that Google and Microsoft made a bad decision choosing Atom? No, absolutely not! Their decision was very good. Microsoft is using Atom for Windows Live API and Google’s using it for most of their applications. What do these have in common? They all manipulate web content. They have a domain where many things are accessible on the web, with lots of URIs, different media types, pagination, categories, tags, etc. Atom makes a lot of sense with web content.

I don’t think Atom is a Silver Bullet for RESTful web services in general. Of course you can choose to always use it, and benefit from the standards and the avaiable tools. But isn’t this true for SOAP as well?

What I do think is that Atom is very close to a Silver Bullet when you’re dealing with web content. Whenever you’re developing web services, choosing the right format for your data exchange is one of the most important decisions. To know well the avaiable options is very helpful, and certainly the Atom format brings a lot to the table when your domain meshes well with it. As long as you don’t think it’s the best choice for every application, go ahead and use it wisely