Começando do começo: o que é Hypermedia?

Hypermedia é uma extensão lógica de Hypertext, na qual conseguimos combinar gráficos, áudio, vídeo, texto plano e hyperlinks para criar um fluxo de navegação não-linear. (Definição retirada da Wikipedia).

Motivação: REST sem Hypermedia

No artigo de REST que escrevi no começo de 2008 eu falei sobre diversos aspectos importantes em um protocolo de comunicação REST. Recomendo a leitura para quem ainda não tenha visto o artigo. Naquele artigo, cobri praticamente todos os detalhes aos quais devemos prestar atenção – a exceção ficou por conta de Hypermedia.

Para ilustrar uma resposta REST sem uso de Hypermedia, copio aqui uma listagem que usei no artigo de REST da Java Magazine.

HTTP/1.1 200 OK
Date: nnn
Content-Type: text/xml; charset=utf-8
Content-Length: nnn
Last-Modified: Sat, 19 Feb 2008 13:40:03 GMT
 
<?xml version="1.0" ?>
<ofertasDoItem>
<oferta>
<codOferta>23c32440-959a-4c33-b6ee-caff8e41422a</codOferta>
<valor>111.22</valor>
<dataModificacao>2008-02-05</dataModificacao>
<item>
<codItem>b7d24e54-0c0d-4fa0-b4fe-d7cf60180ed7</codItem>
<novo>false</novo>
<vendido>false</vendido>
</item>
<ofertante>
<codUsuario>505ab9d4-4b4b-4ce6-b128-b7408268126c</codUsuario>
</ofertante>
<vencedora>false</vencedora>
</oferta>
<oferta>
<codOferta>41ffac11-5ba2-405b-acc8-8e3d0904b158</codOferta>
<valor>111.22</valor>
<dataModificacao>2008-02-14</dataModificacao>
<item>
<codItem>b7d24e54-0c0d-4fa0-b4fe-d7cf60180ed7</codItem>
<novo>false</novo>
<vendido>false</vendido>
</item>
<ofertante>
<codUsuario>505ab9d4-4b4b-4ce6-b128-b7408268126c</codUsuario>
</ofertante>
<vencedora>false</vencedora>
</oferta>
</ofertasDoItem>

Se você julga que isso parece um grafo de objetos serializado, você não está enganado, é exatamente isso.

O que temos a ganhar com Hypermedia?

Quando implementamos a API REST da autenticação/autorização/cadastro da Globo.com, o protocolo REST sem Hypermedia atendeu perfeitamente. A comunicação funcionou, permitiu integração de clientes de todas as plataformas, de forma desacoplada tecnologicamente. No que será que Hypermedia poderia ajudar?

O cerne do benefício de Hypermedia está no conhecimento prévio que os clientes devem ter sobre o seu protocolo. Repare no seguinte fragmento da resposta:

<item>
<codItem>b7d24e54-0c0d-4fa0-b4fe-d7cf60180ed7</codItem>
<novo>false</novo>
<vendido>false</vendido>
</item>

O que podemos dizer sobre ele? Ele traz informações “quase” completas sobre o item em questão. Todos os atributos estão presentes, porém não dizemos nada ao cliente sobre como interagir com este recurso, não é verdade? Um cliente que receba este XML conseguirá manipulá-lo SE JÁ SOUBER PREVIAMENTE COMO! O cliente já deve conhecer as URIs de cada recurso e saber quais manipulações ele pode fazer sobre os mesmos.

Como Hypermedia pode nos levar além? Com Hypermedia podemos dizer aos clientes como manipular os recursos, e com isso diminuir a inteligência embutida nos clientes.

Exemplo de resposta usando Hypermedia

Agora pegarei um trecho do meu artigo sobre AtomPub para exemplificar uma resposta com uso de Hypermedia:

<?xml version="1.0" encoding="UTF-8"?>
<atom:entry xmlns:atom="http://www.w3.org/2005/Atom"
xmlns:apps="http://schemas.google.com/apps/2006"
xmlns:gd="http://schemas.google.com/g/2005">
<atom:id>https://www.google.com/a/feeds/example.com/user/2.0/SusanJones</atom:id>
<atom:updated>1970-01-01T00:00:00.000Z</atom:updated>
<atom:category scheme="http://schemas.google.com/g/2005#kind"
term="http://schemas.google.com/apps/2006#user"/>
<atom:title type="text">SusanJones</atom:title>
<atom:link rel="self" type="application/atom+xml"
href="https://www.google.com/a/feeds/example.com/user/2.0/SusanJones"/>
<atom:link rel="edit" type="application/atom+xml"
href="https://www.google.com/a/feeds/example.com/user/2.0/SusanJones"/>
<apps:login userName="SusanJones" suspended="false" admin="false" changePasswordAtNextLogin="false" agreedToTerms="true"/>
<apps:name familyName="Jones" givenName="Susan"/>
<gd:feedLink rel="http://schemas.google.com/apps/2006#user.nicknames"
href="https://www.google.com/a/feeds/example.com/nickname/2.0?
username=Susy-1321"/>
<gd:feedLink rel="http://schemas.google.com/apps/2006#user.emailLists"
href="https://www.google.com/a/feeds/example.com/emailList/2.0?
recipient=us-sales@example.com"/>
</atom:entry>

Qual é a principal diferença aqui? Através do uso de links conseguimos indicar uma URI para manipulação do recurso, e através do atributo rel, indicamos QUAL é a manipulação. Algumas coisas ainda ficam implícitas. Por exemplo, se o link indica um rel=”edit”, a manipulação em questão provavelmente será feita com uma requisição HTTP PUT. Se o link tiver um rel=”show”, a manipulação deve ser uma leitura, feita com HTTP GET.

Hypermedia x Acoplamento

Neste ponto deve ter ficado claro que o uso de Hypermedia confere maior significado ao protocolo de comunicação. Em vez de trafegar dados crus, enviamos também metadados que permitem a construção de clientes mais genéricos dos nossos serviços.

Reduzindo o conhecimento que os clientes têm sobre o servidor, naturalmente o acoplamento diminui. O servidor precisa manter fixa apenas  a URI inicial da conversação, pois as posteriores serão informadas durante a comunicação.

O servidor pode também utilizar múltiplos tipos de conteúdo, de forma que alguns clientes consigam interagir de forma mais ampla. Um exemplo seria um IPod que sabe consumir podcasts, enquanto estes seriam ignorados por um browser comum.

Precisamos de Hypermedia em um protocolo REST?

Resposta curta: na minha opinião não.

Resposta longa: espero que minha resposta curta não tenha deixado a impressão de que não valorizo Hypermedia. Muito pelo contrário, acho que um protocolo que use Hypermedia será muito elegante e terá baixo acomplamento.

Entretanto, construir protocolos para clientes genéricos é bem mais difícil. Em alguns casos a decisão de diminuir o acoplamento aumenta na mesma proporção a complexidade do protocolo de comunicação envolvido.

É perfeitamente possível criar um excelente protocolo de comunicação sem Hypermedia. Você poderá ter clientes de múltiplas plataformas, conversando com seu servidor em múltiplos formatos de conteúdo.

Há um ponto de atenção no quanto seus clientes conhecem sobre seus formatos de URIs. Sem Hypermedia, mudanças de URIs podem quebrar seus clientes, o que traz um nível de acoplamento maior do que o existente com Hypermedia.

Recomendação geral: o uso de Hypermedia é consistente com a arquitetura da web, utilizada há muitos anos com sucesso. Quando um protocolo de comunicação REST faz uso de Hypermedia, o acoplamento fica baixo e nos dá bastante liberdade para evolução. O ideal é tentar usar Hypermedia ao máximo desde o começo, mas sempre ponderando o nível de complexidade na construção dos clientes.

O código é bem sucinto e simplório, somente com o necessário para falar do que quero. Primeiro a classe JsonController, com 2 métodos que serão acessados pelo client jQuery. Um deles ilustra uma requisição com sucesso e o outro uma requisição com erro.

import java.util.ArrayList;
import java.util.List;
 
import br.com.caelum.vraptor.Get;
import br.com.caelum.vraptor.Path;
import br.com.caelum.vraptor.Resource;
import br.com.caelum.vraptor.Result;
import br.com.caelum.vraptor.view.Results;
 
@Resource
public class JsonController {
 
	private Result result;
 
	public JsonController(Result result){
		this.result = result;
	}
 
	@Get
	@Path("/json/erro")
	public void jsonErro(){
		List<String> erros = new ArrayList<String>();
		erros.add("Erro 1");
		erros.add("Erro 2");
                //Results.http() em vez de Status.badRequest(), pois este força uma página de erro, que ñ serve p/ um cliente ajax 
		result.use(Results.http()).setStatusCode(400); 
		result.use(Results.json()).from(erros, "erros").serialize();
		return;
	}
 
	@Get
	@Path("/json/sucesso")
	public void jsonSucesso(){
		List<String> strings = new ArrayList<String>();
		strings.add("Texto 1");
		strings.add("Texto 2");
		result.use(Results.http()).setStatusCode(200);
		result.use(Results.json()).from(strings, "strings").serialize();
		return;
	}
}

Observação importante sobre o Controller: quem me conhece sabe da minha predileção por bons designs com REST, então neste exemplo essa premissa é seguida. O caso de sucesso retorna um HTTP 200 indicando o sucesso, e o caso de erro retorna HTTP 400 (Bad Request), indicando ao cliente que sua requisição tinha problemas que precisam ser corrigidos.

Ambos os casos retornam JSON para o cliente Ajax. No caso de sucesso o jQuery consome isto diretamente. No caso de erro o JSON com os erros será consumido do responseText do XmlHttpRequest.

Criei um HTML simples para teste, com 2 botões para gerar os requests ajax de sucesso e de erro.

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=UTF-8" />
<title>Ajax com validação</title>
</head>
<body id="public">
<div id="container">
<h1 id="logo"></h1>
<form id="teste-json" name="teste-json" enctype="application/x-www-form-urlencoded" method="post" action="/json/erro">
 
<div class="info"><h2>Teste JSON</h2></div>
<div class="info">
<ul id="campos-cadastro">	
	<li class="buttons ">
	<div><input id="erro" name="erro" type="button" value="Teste Erro" /></div>
	</li>
	<li class="buttons ">
	<div><input id="sucesso" name="sucesso" type="button" value="Teste Sucesso" /></div>
	</li>	
</ul>
</div>
</form>
</div>
<img id="bottom" src="/images/bottom.png" alt="" />
<script type="text/javascript" src="/scripts/jquery-1.4.2.min.js"></script>
<script type="text/javascript" src="/scripts/teste-json.js"></script>
</body>
</html>

Para completar, o javascript que trata do clique nos botões, faz os requests e consome o JSON de sucesso e o JSON com as mensagens de erro.

$(document).ready(function(){ 
	$("input#erro").click(function() {
		$.ajax({
		   type: "GET",
		   url: "/json/erro",
		   dataType: "json",
		   success: function(json){    		
    		for (var x = 0; x < json.erros.length; x++) {
    			var erro = json.erros[x];
    			alert("Erro: " + erro);
    		}    	    
    	  }
    	}); 
    });
 
	$("input#erro").ajaxError(function(e, xhr, settings, exception) {
		var errosStr = xhr.responseText;
		var json = eval("(" + errosStr + ")");		
		for (var x = 0; x < json.erros.length; x++) {
			var erro = json.erros[x];
                        alert("Erro: " + erro);
		}
	});
 
	$("input#sucesso").click(function() {
		$.ajax({
		   type: "GET",
		   url: "/json/sucesso",
		   dataType: "json",
		   success: function(json){    		
    		for (var x = 0; x < json.strings.length; x++) {
    			var texto = json.strings[x];
    			alert("Texto: " + texto);
    		}    	    
    	  }
    	}); 
    });
 
	$("input#sucesso").ajaxError(function(e, xhr, settings, exception) {
		var errosStr = xhr.responseText;
		var json = eval("(" + errosStr + ")");		
		for (var x = 0; x < json.erros.length; x++) {
			var erro = json.erros[x];
			alert("Erro: " + erro);				 
		}
	});    
});

Para quem tiver interesse no assunto, recomendo demais a leitura dessa thread. A discussão é de altíssimo nível, e certamente pode trazer várias idéias bacanas.

“Hi blpsilva,

Why don’t you tweet or blog this? Use the hashtag #bestofslideshare so we can track the conversation.”

A única apresentação que coloquei até hoje foi a de Web Service REST, logo após o aniversário do CEJUG ano passado. Acessei minha conta lá e vi que a apresentação lá passou de 30 mil visualizações, em 6 meses. Eu não imaginava que isso pudesse ter um alcance tão grande, fiquei bem contente. Seems like I’m doing something right

Preciso em algum momento preparar mesmo um curso de Web Services, incluindo REST e WS-*, já que o interesse nisso parece grande, e eu venho acumulando muita experiência nessa área.

Uma idéia que tive um tempo atrás seria de discutir aqui no blog algumas dúvidas sobre como utilizar REST e Web Services de forma efetiva em situações reais. Eu já conversei com muitas pessoas sobre isso, e algumas dúvidas são freqüentes, e outras são mais sofisticadas e diferentes. Eu terei um enorme prazer em discutir isso aqui, pois me trará situações novas para analisar e é um exercício interessante que pode contribuir para mim e para outras pessoas que estejam trabalhando na área.

Vou saborear meu momento de RockStar do SlideShare então, e incentivo a todos que queiram propôr discussões sobre REST (e web services em geral) que entre em contato para vermos o que surge de interessante

Esta migração tem muitos aspectos semelhantes à que fizemos no time de cadastro/autenticação no ano passado, e eu já conversei algumas vezes com o pessoal do ISP sobre isso, pois conheço bem o domínio deles. Entretanto, o domínio do ISP é um pouco mais complexo que o do cadastro, e isso torna a modelagem de recursos um pouco mais sofisticada e interessante.

O exemplo que vou descrever aqui é o do Comando CmdFinalizaCompra. Este Comando é invocado no final de qualquer operação do ISP que modifique a cesta de produtos/serviços do assinante. Pelo próprio nome, fica óbvio que ele foi constituído de maneira imperativa (“FazerEstaOperacao”), e o pessoal estava em dúvida sobre como redesenhar este modelo e colocá-lo num desenho declarativo, à maneira RESTFul.

Vou mencionar resumidamente a estrutura de comunicação dos comandos do ISP para que o resto da discussão fique claro. Cada Comando é constituído de 2 classes Java. CmdNomeComando e CmdNomeComandoSrv. A primeira classe corresponde ao Comando do lado do cliente, e a segunda corresponde ao Comando do lado do servidor.

Na execução do comando, o cliente invoca um EJB 2.1 stateless no servidor, e envia a classe CmdNomeComando serializada, via RMI. O servidor recebe a classe, deserializa-a, executa a operação em questão e retorna a classe novamente para o cliente, com ou sem modificações, dependendo do caso.

Este modelo é semelhante à chamada de serviços SOAP, em que é invocada uma operação SOAP com um documento XML de entrada e alguma coisa na saída.

Podemos ver a classe CmdNomeComando como o “parâmetro de entrada” da operação, e a classe CmdNomeComandoSrv como a implementação da operação em questão. Este exemplo do CmdFinalizaCompra envolve vários componentes do modelo do ISP. Não sei dos detalhes de cabeça, mas este processo envolve Assinante, Usuario, Produto, Promocao, Desconto e possivelmente mais alguns elementos do domínio.

Assim, um objeto CmdFinalizaCompra é composto de vários objetos deste domínio. A dúvida deles é sobre a definição dos recursos neste contexto. É uma dúvida pertinente, pois isto foge bastante a um CRUD óbvio. Uma possibilidade de desenho definiria como recursos: Assinante, Usuario, Produto, Promocao e Desconto. Isto seria mapeável diretamente na implementação do domínio deles. O que vocês acham disso?

Bom, não vejo nada errado em expor um recurso Assinante, outro Usuario, etc. Isto pode fazer sentido para outras “operações”, maravilha. Entretanto, para este caso isso levantou a seguinte dúvida para eles: “Eu vou ter que fazer vários POSTs para realizar a operação do CmdFinalizaCompra” ?

Imagine a complexidade de garantir o sucesso transacional dos vários POSTs independentes que compõem esta operação! No universo WS-* existe o conceito chamado Orquestração, no qual um determinado componente agrega e invoca várias operações pequenas em uma única operação/transação. Utilizando nomes pomposos, isto seria um Proxy Service invocando alguns Business Services. Algum de vocês se sente tentado a usar esta abordagem? Eu não!

O que eu sugiro neste exemplo é a criação de um recurso chamado Compra, que pode ser representado por um grafo sofisticado de objetos do domínio do ISP. Para substituir o CmdFinalizaCompra, eu vejo a criação de uma instância do recurso Compra, com todas as informações pertinentes à compra em questão. A criação deste recurso estaria associada a uma única transação, seja lá o que tenha que ser feito por baixo dos panos no servidor.

Na implementação do servidor, eu vejo somente este POST sendo realizado. O cliente não precisa saber (e é melhor que não saiba) como é implementado o domínio no servidor. Ele precisa conhecer os recursos expostos, e como interagir com eles.

Pense numa compra na Amazon, por exemplo. Eles poderiam expôr este mesmo recurso Compra que eu falei, que seria composto pelos produtos, pelo cliente e talvez a opção de pagamento.

Isso seria exposto pelo recurso, mas dentro da Amazon uma compra poderia envolver N operações: reserva de estoque, criação de ordem de entrega, lançamento da cobrança, criação de comissão para o distribuidor, etc. O cliente do Recurso só conhece os detalhes do que foi exposto, e isso não implica em detalhes de implementação no servidor.

Lembrem que um dos principais objetivos para uma arquitetura RESTFul é ter baixo acoplamento, então tenham a liberdade de modelar seu domínio e seus recursos como fizer mais sentido.

Na Globo.com eu trabalhei muito com open source, e estava acostumado a montar as aplicações a partir de componentes “crus”, em vez de usar ferramentas sofisticadas. Open source faz parte da cultura da empresa, e tínhamos uma boa liberdade de escolha de tecnologias e arquiteturas.

Como falei algumas vezes no passado, nós migramos boa parte da arquitetura legada com EJBs para serviços REST usando por baixo o Jersey, Spring e Ibatis. A produtividade no desenvolvimento de serviços REST me agrada muito, e mesmo alguém que não conheça muito de serviços REST consegue desenvolver um serviço sem tanto esforço.

Agora vou trabalhar mais com serviços SOAP, mas usando ferramentas muito produtivas, como o Aqualogic ESB e o Workshop, entre outros. Essas ferramentas facilitam muito o trabalho oferecendo Abstrações Opacas. Como ainda estou muito ligado ao trabalho com Open Source, eu venho tentando no meu tempo vago encontrar ferramentas open source com a mesma proposta.

Neste momento estou tentando encontrar a maneira mais produtiva de se trabalhar com web services SOAP usando open source. No passado eu desenvolvi serviços com o XFire, com o Axis 2 e com o JAX-WS, mas achei interessante reavaliar as opções existentes atualmente.

Nos últimos dias eu fiz testes com o Axis 2, com o Apache CXF e com o JAX-WS.

Eu não gosto muito do Axis 2. Você até consegue desenvolver serviços rapidamente com ele, mas ele gera um código tão sujo que é muito triste colocar qualquer coisa em produção com ele, sabendo que você vai ter que manter depois aquele código. Além disso, para utilizá-lo você precisa levar nada menos que 51 jars para sua aplicação, o que transforma qualquer aplicação em um mastodonte. Um outro problema dessa lista massiva de dependências é que a chance de uma aplicação pré-existente ter conflitos de dependências com o Axis é grande.

Na prática, eu só utilizaria o Axis 2 (e mesmo assim com má vontade) para desenvolver serviços se fosse numa estrutura como o WSO2 Web Services Application Server, que é um servidor de aplicações “dedicado” a serviços Axis.

O Apache CXF oferece um “front-end” com JAX-WS (que é o mais recomendado) e um “front-end” alternativo, que usa o Aegis Databinding. Por enquanto olhei apenas o front-end com JAX-WS, mas não vi nenhuma vantagem em utilizar o CXF em vez da implementação de referência presente no Glassfish. Se pintar disposição eu darei uma olhada no front-end com Aegis Databinding, mas por enquanto não tenho grandes expectativas em relação a ele não.

Para finalizar, fiz muitos experimentos com a implementação de referência do JAX-WS, embutido no Glassfish V2. A forma de trabalho que achei mais produtiva nestes meus testes foi desenvolvendo com JAX-WS no Netbeans (utilizei a versão 6.5).

Tentei desenvolver a partir de classes Java, e a partir do WSDL, e esta última me trouxe melhores resultados.A melhor forma que achei foi começar desenhando os schemas XML com o editor do Netbeans:

Criei um Complex Type para cada classe de domínio, e 1 Complex Type para o Request de cada operação e 1 Complex Type para o Response de cada operação. Tendo feito isso, criei depois 1 Element para o Request de cada operação e 1 Element para o Response de cada operação. Com o schema XML criado dessa forma, criei em seguida o WSDL, com o editor do Netbeans também:

Na criação do WSDL, coloquei nas mensagens de Request/Response das operações os Elementos declarados no schema XML anterior. É importante prestar atenção nisso. Usando Elementos nas mensagens, você está criando serviços no modelo Document/Literal. Se você colocar nas mensagens um Complex Type diretamente, em vez de colocar um Elemento, você estará criando um serviço no modelo RPC/Literal. Eu particularmente prefiro Document/Literal, e o código gerado pelo JAX-WS neste modelo me agrada mais.

A implementação do serviço com JAX-WS ficou parecida com isso aqui:

package org.brunopereira.cadastro;
import javax.jws.WebService;
import org.brunopereira.schema.cadastroclientes.CadastroClienteRequestType;
import org.brunopereira.schema.cadastroclientes.CadastroClienteResponseType;
import org.brunopereira.schema.cadastroclientes.Cliente;
import org.brunopereira.wsdl.cadastrocliente.CadastroClientePortType;
 
@WebService(serviceName = "CadastroClienteService", portName = "CadastroClientePort",
endpointInterface = "org.brunopereira.wsdl.cadastrocliente.CadastroClientePortType",
targetNamespace = "http://brunopereira.org/wsdl/CadastroCliente",
wsdlLocation = "WEB-INF/wsdl/CadastroCliente/CadastroCliente.wsdl")
public class CadastroCliente implements CadastroClientePortType {
public CadastroClienteResponseType cadastrarCliente(CadastroClienteRequestType request) {
System.out.println("Cadastro de cliente foi invocado!! Será feito o roteamento para o serviço adequado!!");
Cliente cliente = request.getCliente();
CadastroClienteResponseType response = new CadastroClienteResponseType();
response.setCliente(cliente);
return response;
}
}

O código do cliente foi gerado bem facilmente a partir do WSDL também, e ficou bem limpo. O que achei bem fraco foi a parte de teste dos serviços tanto no Netbeans como no Eclipse. No Eclipse você só consegue usar os plugins de teste se você tiver desenvolvido os serviços dentro do Eclipse, o que inviabilizou o meu uso. E o Netbeans tem um suporte que só serve pra HelloWorld, pra aqueles serviços de Calculadora, que você passa uns parâmetros primitivos e recebe um resultado simples. A interface do testador do meu serviço ficou dessa forma:

Dá pra ver que não serve para nada além de um HelloWorld basicão.

Bom, de uma maneira geral, o suporte a Web Services no Netbeans é muito melhor do que no Eclipse, que pra piorar só suporta a criação de serviços com o Axis. Até agora a maneira mais produtiva que encontrei de trabalhar com serviços SOAP foi essa que descrevi. Nos próximos dias olharei o que tem de interessante no projeto Metro e no JBoss ESB. Se encontrar coisas interessantes falarei mais por aqui. Ah, e se alguém tiver dicas para melhorar esta forma de trabalho que descrevi, por favor me avisem, pois estou avaliando muita coisa e não dá tempo de dedicar tanto tempo a cada opção dessas.

Eu levarei várias boas lembranças, de um período que foi muito positivo para mim. Comparando a minha experiência e maturidade agora com o momento em que entrei na Globo, a diferença é enorme. Tive a oportunidade de trabalhar com profissionais de altíssimo nível e em projetos de enorme importância técnica e de negócio. Tive também a sorte de atuar em áreas com as quais tenho muita afinidade e interesse, o que ajuda bastante no envolvimento de qualquer profissional.

Quando cheguei à Globo pude vivenciar uma situação nova para mim. Passei a ter a satisfação de ir trabalhar feliz todos os dias. Atuando em um ótimo ambiente de trabalho no qual o software fica em primeiro plano. Com o benefício extra de saber que meu trabalho teria a visibilidade do maior portal de internet da América Latina.

Além disso, posso dizer que vivi muitos progressos dentro da empresa. Acompanhei o surgimento de produtos como o G1, o 8P, o Futpedia e o Musas, além de um progresso fantástico na plataforma de Vídeos. Acompanhei de perto a produção interna para eventos como a Copa de 2006 e as Olimpíadas de Pequim. Poder vivenciar esse crescimento da empresa foi muito interessante.

Também me deixou muito feliz a abordagem da Globo.com em relação a Open Source. Quando cheguei na empresa, todo mundo usava Windows, o servidor de aplicações mais usado era o Weblogic e embora já existisse o uso de muitos softwares open source, isso não fazia parte da cultura da empresa.

Hoje em dia a relação da Globo com Open Source é excelente. Todos apostam no uso de Open Source, os desenvolvedores todos usam Linux, nossos servidores de aplicação são quase todos Open Source, já há vários projetos com banco de dados open source, e a maturidade dos profissionais em relação a Open Source aumentou muito. Pra mim isso foi muito gratificante. Durante mais de 1 ano e meio eu tive a satisfação de trabalhar full time com Linux, e acredito que consegui contribuir um pouco também para que outros utilizassem de forma produtiva.

Ainda mais importante do que a relação com open source foi a adoção de metodologias ágeis. Quando cheguei na Globo.com a maioria dos projetos era no estilo Waterfall. Não é necessário explicar com detalhes aqui, mas era muito perceptível que os projetos não andavam na velocidade que poderiam.

Aos poucos o Scrum começou a ser utilizado, e alguns meses depois isso desencadeou uma série de mudanças positivas na empresa. Este ano inteiro eu trabalhei em um time Scrum, e foi uma experiência excelente. Passamos a ter uma equipe multi-disciplinar, tendo contato diário com um designer, com um arquiteto de informação e um desenvolvedor client-side. Isso foi muito benéfico para mim. Acompanhar de perto o trabalho de profissionais de outra especialidade me ensinou muito sobre a atuação deles, e claro, aprendi muito sobre client-side e passei a gostar disso, o que é fundamental para qualquer desenvolvedor web.

Ao longo do ano nós amadurecemos muito a nossa forma de trabalho, e a utilização de práticas ágeis foi fundamental nisso. Claro que ainda existem arestas a serem aparadas e pontos que precisamos melhorar, mas sem dúvida nosso time evoluiu muito esse ano.

Tecnicamente o ano foi muito bom para mim também. Participei de projetos muito interessantes como a migração para o e-mail no Google, onde atuei diretamente na integração entre as empresas. Outros projetos muito bacanas foram o novo cadastro e a nova Central do Usuário.

O projeto de integração com o Google foi o primeiro projeto crítico no qual utilizamos REST, e como tivemos muito sucesso, todas as nossas aplicações já estão usando REST, e falta mais um pouquinho só para que nossa arquitetura seja 100% migrada de comunicações via EJB para REST. Aprendi muuuuuuuito nesse processo, foi uma experiência excelente.

Os projetos do Cadastro e da Central foram muito interessantes do ponto de vista de produto e do ponto de vista de desenvolvimento. As 2 aplicações foram desenhadas para terem módulos dinâmicos de cadastro. Isso permite que cada produto tenha o seu próprio template de cadastro, e as informações requisitadas dos usuários são configuradas por uma ferramenta de administração.

O desenvolvimento destas aplicações exigiu um trabalho muito interessante de modelagem e desenvolvimento, com muitas refatorações até que chegássemos no modelo final. Aprendi muito também com esses dois projetos.

Mas nem só de software vive uma pessoa   Nesse meu período na Globo.com eu conheci muitas pessoas fantásticas e fiz muitos amigos. O ambiente de trabalho e as pessoas da Globo.com são um dos maiores motivos para que tenha sido tão legal trabalhar na empresa, e com certeza vou sempre me lembrar disso.

Meu time de desenvolvimento esse ano é muito bem entrosado e positivo. Tacaram na mesma mistura 2 cariocas, 1 capixaba, 1 prudentino e 1 paraense, e deu muito certo Gostei muito da experiência, e vou com certeza sentir falta desses picaretas

Estou indo agora para um novo projeto na Concrete, atuando na Globosat. O pouco que sei do projeto até agora me pareceu muito interessante, e essa mudança de cliente é fundamental para as minhas perspectivas dentro da empresa. Torço muito para essa minha nova empreitada seja tão interessante e produtiva como meu período dentro da Globo.com, e claro, espero contribuir bastante para o sucesso da Concrete em um novo cliente e novo projeto.

No final das contas, sinceramente espero que eu tenha contribuído tanto com a Globo.com quanto ela contribuiu para a minha carreira e o meu amadurecimento. Foram 2 anos e meio sensacionais e tenho certeza de que a empresa continuará no seu caminho de enorme sucesso, que pude acompanhar neste período.

Chegou então o momento de dizer Adeus Globo.com, foi um grande prazer para mim!

I’m using Jersey (the JSR’s reference implementation) for more than 6 months and I was anxious to have the specification approved.

In my team we’re currently using Jersey 0.7 in production, and were waiting for the JSR to be approved to analyse the final version of its implementations. Now we’ll wait for both Jersey and JBoss RESTEasy to release their final versions and we’ll analyse both to see which one we’ll use in our RESTFul services.

If anyone wants to give me good reasons to use either one of the implementations, now it’s the perfect time! I’m hearing…

After looking better at WSO2 Registry, I figured out how to do what I need with the product. I had a very short time to evaluate properly WSO2 Registry and Mule Galaxy before my last post, but after another evaluation of them, I concluded I can use them in this case.

Last week I developed a Java client to consume my publications from WSO2 Registry. It wasn’t much fun to develop, because I had to make it compatible with JDK 1.4. This prevented me from using their client API, which runs only on JDK 1.5 and above.

Since I had to use JDK 1.4, I used XStream for my Java <-> XML mappings. Not being able to use the Registry’s Java client, I also had to consume data from their AtomPub API. I used Apache Abdera 0.3 for this task, which was their last version supporting JDK 1.4 (through retroweaver).

So far so good. Last week I had a prototype client consuming stuff from the Registry, so I moved on to some other tasks. Well, today I started integrating the Registry in my application. That meant moving from Tomcat 6 to JBoss 4.0.5. And that’s when I got in trouble.

Unfortunately I hadn’t seen this page before. It turns out that the only application server they have tested enough is Tomcat. And not any Tomcat, only Tomcat 6. Since their distribution format is a .war file, I never would think they support only Tomcat. In their download page it says: “This distribution includes the Webapp module with relevant JAR files and other resources to be deployed in the servlet container, providing a Web UI and an APP interface.”

Well, I’m probably just dumb. They didn’t say “a servlet container“. They said “the servlet container“. This certainly means “the servlet container we support, which is Tomcat 6″. But this is not written there, so dumb people like me will be subject to mistakes.

“Heck, this is open source, I’m gonna make it work on JBoss!”. This was my first thought. And then I started setting up the Registry in JBoss, right after lunch today.

The first thing I noticed is that the Registry packs a newer version (1.2.13) of log4j than the one present in JBoss (1.2.8). This shouldn’t be a problem, but anyone who has experienced some of the JBoss Classloader Hell knows that it’s not a wise decision to bring a newer version of log4j inside your application if you’re going to run on JBoss. This is not a Registry fault, so I gladly fixed the problem by removing the log4j they had packed inside the .war file.

After fixing this, I was gettings errors trying to open the Registry’s index page on JBoss. I quickly found out that their jsps had scriptlets using JDK 1.5 code, and JBoss was not able to compile the jsps. This was easy to fix by uncommenting a init-param in the web.xml in the Tomcat module inside JBoss. However, the amount of scriplets inside their pages was the first symptom that something didn’t smell right.

After fixing the jsp problem, I configured the Registry to connect to MySql through a JBoss datasource. I then could open their index page and even use some features. However, when I started checking the server logs I was shocked. A huge amount of errors in jdbc operations. I had no clue of what was going wrong, because the UI was apparently working normally and the database was being manipulated.

Well, since it’s an open source product, I promptly checked out their code and started looking for problems. Most errors occured in simple jdbc operations like the creation of a prepared statement. The application logs were not very helpful, and I couldn’t figure out where the problem was.

However, something scared me a lot. Between the zillions of jdbc errors, I saw JBoss screaming for help, saying that the PreparedStatements were left open. I went to look at their jdbc code, and it definitely needs care. There were a LOT of jdbc operations inside try/catch blocks, where they treated SQLExceptions. I didn’t see the finally blocks closing the PreparedStatements and the ResultSets. This explains JBoss’s complaints about the PreparedStatements.

After several hours trying to use WSO2 Registry inside JBoss and looking at their code, I must say I am VERY discouraged to put anything in production right now using the product.

I just downloaded Mule Galaxy and now I’m gonna try to integrate it in my application. A very good sign is that they say I can use it with ANY servlet container, including Tomcat and Jetty. I think it’ll be a successful effort, but it’s hard to say anything after my problems with WSO2 Registry today.

But knowing Dan Diephouse’s work for several years, I’m pretty confident in this new attempt. I’ll post the results later this week.

One of the main issues with the old architecture is the tight coupling between the server and the clients. The way it was designed, our server platform is limited by the oldest client’s platform.  To have more flexibility and loose coupling between server and clients, we decided to have an XML contract in the communication.

In this Sprint we must finish the implementation of a Java client to be distributed to the client applications. We have some optimization and refactoring tasks for this Sprint, and one of them includes a RESTFul registry. We don’t want the clients to have our URIs configured via properties files. This approach limits our flexibility to manage URIs, so a different approach is desirable.

Our client will access a repository to ASK FOR the URI corresponding to a given service AND version. That means: the client willing to access the login service will ask the repository for the URI of this service, in the client’s version. The client could ask for /repository/login/v2.0 and then receive back the URI http://login.globo.com/login/v2.0.

We could have several different versions of the same services, each of them with different contracts. Introducing the repository as an extra layer of indirection, we also have the flexibility to take down several server machines for a while and even update URIs if desired (although that’s unlikely).

I checked Mule Galaxy and WSO2 Registry, but unfortunately they don’t give me what I need. They’re both open source registries, but they index SOAP services and some other things, but not RESTFul URIs. They offer a REST API to interact with their registries (unlike UDDI, which uses SOAP), but don’t index RESTFul URIs at this moment.

After this analysis of both, i decided to implement my own RESTFul registry. It shouldn’t be too sofisticated for this first release, but since it’s a frequent need in my team, I’m probably going to take some off-time to develop a nice registry that might be useful for a wider range of applications. My goal with this post is to gather some requirements for this registry and also its client. Features that would be useful for other people too.

The initial set of requirements that I wanna deliver in this Sprint is:

• Must have a RESTFul API to search for services
• Should be possible to browse published services with a web browser (even IE, if you call it a browser)
• Ajax clients should be able to access the registry easily
• Java client must run on JDK 1.4 and above
• Java client should require as few libraries as possible
• Registry should access the database through a JDBC datasource
• Offer an authenticated user interface to publish the services (probably with Java EE authentication)

An extra list of desirable features (not for this Sprint) is:

• Import service URIs from WADL document
• Allow database access without a JDBC datasource
• Show history of modifications in the registry
• Registry should be distributed as .war
• Offer other ways of authentication

Well, that’s the first ideas that come to my mind. My intention is to implement a nice registry and offer it for everyone to use it. If you think of some other features that would be nice in the registry, please let me know. The idea of this post is to be an asynchronous brainstorm, so please help!