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.

Tive este problema em um ambiente de QA essa semana e vou deixar aqui informações que devem solucionar a maioria dos problemas relacionados. Há 2400 resultados no Google sobre MySQLNonTransientConnectionException, deve ter ocorrido muito já.

Esta exceção é lançada quando uma aplicação Java tenta utilizar uma conexão, mas ela já foi fechada no MySql. Os cenários mais comuns para isso são:

• MySql foi reiniciado
• Problema de rede na conexão com MySql
• Conexão ficou ociosa tempo demais, e o MySql fechou-a

Estes cenários podem ser raros na sua infra, mas é importante que sua aplicação consiga lidar com isso. Minha aplicação usa o Hibernate, conectado a um pool de conexões do JBoss. O datasource em QA estava configurado assim:

<datasources>
  <local-tx-datasource> 
    <jndi-name>NomeDS</jndi-name>
    <connection-url>jdbc:mysql://servidormysql:3306/nome_schema</connection-url>
    <driver-class>com.mysql.jdbc.Driver</driver-class>
    <user-name>usuario</user-name>
    <password>senha</password> 
    <min-pool-size>1</min-pool-size>
    <max-pool-size>20</max-pool-size>    
    <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter</exception-sorter-class-name>
    <metadata>
       <type-mapping>mySQL</type-mapping>
    </metadata>
  </local-tx-datasource> 
</datasources>

A solução no meu caso foi incluir um novo parâmetro no datasource indicando uma query para o JBoss checar se a conexão é válida ou não: <check-valid-connection-sql>select 1</check-valid-connection-sql>. Este elemento é filho de <local-tx-datasource>. Com a introdução deste parâmetro, o JBoss consegue identificar que a conexão já não é válida e então obtém uma nova conexão.

Nas minhas buscas vi muitas pessoas com esse problema rodando no Tomcat sem um pool de conexões. A solução para eles foi criar um pool com C3P0, como nesse exemplo. É importante prestar atenção na configuração para que seja feita a renovação das conexões em caso de falha. Isto parece ser feito com o parâmetro no C3P0: <property name=”connection.provider_class”>org.hibernate.connection.C3P0ConnectionProvider</property>

Observação importante: colocar o parâmetro ?autoReconnect=true na URL jdbc NÃO resolve o problema, só muda a exceção. Além disso, o parâmetro autoReconnect é deprecated e não é recomendada a utilização.

That’s all folks!

Para uma referência dos ratings do Page Speed e YSlow, sites com rating acima de 80 podem ser considerados muito bons. É possível chegar até  90 sem configurações muito complicadas. Até hoje, o site com os maiores ratings que já encontrei em toda a internet é o site da Caelum. Rodei agora os testes e eles estão c/ 96 no Page Speed e 100 no YSlow. O meu blog está c/ 85 no Page Speed e 84 no YSlow

A maioria das técnicas de otimização é simples de aplicar, e é possível ter ótimos resultados com bem pouco trabalho. Escreverei uma série de posts curtos e objetivos explicando as principais técnicas e mostrando como utilizá-las nas arquiteturas mais comumente usadas.

Motivação

Todos os browsers modernos possuem recursos de descompressão de conteúdo, e boa parte dos arquivos servidos em aplicações web podem ser bem comprimidos. Habilitando compressão no servidor o tempo de resposta das páginas diminui, e com isso cai também o tráfego do servidor.

Como fazer

O servidor web mais utilizado na internet é o Apache. Mostrarei inicialmente a configuração somente dele, e caso alguém queira saber também do IIS e nginx, complementarei posteriormente.

Para habilitar a compressão, deve estar ativo mod_deflate. No Ubuntu você pode verificar os módulos ativos listando o diretório /etc/apache2/mods-enabled.

A opção mais simples de configuração é utilizar a diretiva: SetOutputFilter DEFLATE

Esta opção habilita compressão para tudo, no escopo onde for colocada. Podemos habilitar compressão em um virtual host, em um diretório ou até mesmo em todos os arquivos servidos pelo Apache.

Outra opção é habilitar compressão somente para alguns tipos de arquivos, com esta diretiva: AddOutputFilterByType DEFLATE text/html text/plain text/xml

Na documentação do mod_deflate há cenários mais complicados, como verificações do browser, manipulação de cabeçalhos HTTP, consumo de conteúdo comprimido, entre outras coisas. Se alguém tiver dúvidas posso ajudar no setup de testes.

Verificando que funcionou

Para verificar que a compressão está ativa, podemos utilizar o Poster para requisitar uma página do site e conferir o cabeçalho Content-Encoding da resposta, conforme imagem abaixo. Se aparecer o encoding gzip, a compressão está ativa.

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);				 
		}
	});    
});

ANALISTA DE SISTEMAS
Projeto de 3 meses (prorrogável) em país da América do Sul
Fundamental: Inglês fluente
Desejável: Espanhol
Arquitetura SOA
Web Services + WSSE
XPath
XQuery
UML
Orientação a objetos
Modelagem de processos e indicadores (SLA)

Enviar currículos somente EM INGLÊS para:
fernanda.godoy@concretesolutions.com.br

Atenção: Enviar currículos preferencialmente até o dia 07/01/2010, pois as vagas precisam ser preenchidas rapidamente.

Java Senior

Experiência comprovada  de pelo menos 4 anos como programador/desenvolvedor
Java EE 5 e 6
JPA, Hibernate, Struts ou algum framework para a web em Java
Experiência de alguns dos seguintes appplication servers: BEA Weblogoc 9 ou 10, Jboss AS, Apache Tomcat e Geronimo
Conhecimento de plataforma Linux
Conhecimento em shell scripting para Unix/Linux é bastante Desejável
Forma Contratação: Pessoa Jurídica
Obs: Apenas serão considerados os currículos no perfil acima

Ainda está aberta também a vaga de analista de Infra-estrutura, com perfil abaixo:

Analista de Infra-estrutura Pleno/Senior

Obrigatório
- Administração Linux
- Configuração e administração do Apache Web Server
- Shell Script
- Configuração de redes

Desejável
- Configuração e administração Weblogic Server
- Noções de arquitetura Java EE
- Noções de arquitetura SOA

Somente com experiência comprovada.

Os currículos devem ser enviados para marcia.cataldi@concretesolutions.com.br com cópia para bruno.pereira@concretesolutions.com.br.

Obrigatório

- Administração Linux
- Configuração e administração do Apache Web Server
- Shell Script
- Configuração de redes

Desejável

- Configuração e administração Weblogic Server
- Noções de arquitetura Java EE
- Noções de arquitetura SOA

Somente com experiência comprovada.

Os currículos devem ser enviados para marcia.cataldi@concretesolutions.com.br

Meus caros amigos cearenses novamente me honraram com o convite para palestrar no evento comemorativo do 7o aniversário do CEJUG.

O evento ano passado já foi excelente, e este ano promete ser melhor ainda. Este ano o evento será realizado no próximo sábado, dia 19/09, e a grade de programação está sensacional, tendo como palestrantes este humilde sujeito que vos escreve, Régis Melo, Victor Hugo Oliveira, Rafael Ponte e Tarso Bessa, Jeveaux, Rodrigo Yoshima e Paulo Silveira.

A minha palestra será sobre desenvolvimento web produtivo. Falarei de frameworks Java até Rails, Grails e Django, passando por web standards e jQuery. Para completar, uma rica caixa de ferramentas no Firefox. Se você é um caba cearense arretado, não pode perder essa ocasião tão bacana!

No momento atual, temos posições para início imediato e horizonte de longo prazo. Queremos profissionais que tenham paixão por software e sejam auto-motivados, buscando evolução contínua. Profissionais deste perfil encontrarão um ambiente ótimo para seu crescimento dentro da Concrete. A descrição técnica dos perfis pode ser vista a seguir.

Os níveis de experiência são variados, então entre em contato se você se julgar dentro do perfil de profissional que buscamos. Quem quiser mais informações, não deixe de entrar em contato.

Para os poliglotas e pluralistas do conhecimento tecnológico, há projetos acontecendo em Java, .NET, Python e Javascript. Embora não tenhamos posicões disponíveis em todos eles, a troca de conhecimento e a colaboração acontecem naturalmente por aqui, simplesmente porque isso faz parte do nosso DNA. Além disso, como trabalhamos com diferentes domínios conceituais, não é raro alguém sair de um projeto web tradicional e entrar em um que um CMS open source, sair de um outro de comércio eletrônico em Java e partir para um outro em Python com integração, e por aí vai.

Desenvolvedor Java (preferencialmente com experiência em Web e/ou Mobile)

Java SE 5 e/ou 6. Java EE 1.4 e/ou 5.

JPA e/ou Hibernate são bastante desejáveis. Importante conhecer banco de dados relacionais e mapeamento objeto-relacional. Se você conhece SQLAlchemy e já colocou um aplicação em produção com ele, esteja certo que tem grandes chances.

Experiência de uso com alguns dos seguintes application servers: BEA Weblogic 9 ou 10, Jboss AS, Jetty, Apache Tomcat, Geronimo.

Struts, Spring MVC ou outro framework para web em Java. Boa experiência com Grails, Ruby on Rails, Django, Pylons, são válidos, e podem nos interessar mesmo se você não conhecer um framework web Java.
Inglês para leitura e estudo de material técnico.

Desejável

Graduação em Ciência da Computação, Engenharia da Computacão, Informática, Física ou Matemática.

Conhecimento e interesse em outras linguagens de programação é bastante apreciado: Python, Scala, Ruby, Rhino, Javascript, Perl, OCAML, Common Lisp, Brainfuck.

Experiência com Apache e seus módulos mais famosos, como mod_rewrite e mod_jk.

Bons conhecimentos de client-side (HTML, CSS, Javascript) são muito positivos.

Conhecimento de plataforma Linux é desejável, mas não obrigatório.

Conhecimento em shell scripting para Unix/ Linux é muito bem-vindo.

Os interessados devem enviar um e-mail com currículo para marcia.cataldi@concretesolutions.com.br com cópia para bruno.pereira@concretesolutions.com.br

Na última quinta-feira eu fui na palestra do Bruno Borges no RioJUG, sobre Apache Camel. A palestra em si foi bem legal, pois eu já conhecia um pouco do Apache Camel e pude ver algumas coisas a mais. Mas o ponto específico que eu quero abordar é um comentário que o Bruno fez, que diverge da minha postura em relação a open source.

Ele comentou que tenta sempre utilizar produtos Apache, evitando produtos open source que tenham vínculo com alguma empresa, como JBoss, SpringSource, entre outras. Não me recordo do motivo exato, mas a razão principal que ele explicou é o fato da Apache Software Foundation ser uma fundação composta de pessoas, em vez de ser uma empresa com fins comerciais.

Eu tenho uma postura diferente da dele em relação a open source. Eu gosto muito e tenho um respeito enorme pela fundação Apache. Já usei inúmeros produtos Apache e certamente continuarei usando por muito tempo. Entretanto, já usei vários produtos JBoss e vários componentes do Spring, e acho muito importante e saudável a existência dessas empresas.

A história do movimento open source tem vários elementos “românticos” e “filosóficos”, e essa característica ainda é muito presente em várias comunidades hoje em dia. Entretanto, com o crescimento do Linux, Java, Python, Ruby e outras tecnologias, existe hoje um mercado enorme de trabalho e negócios em torno do software livre.

O surgimento desse mercado naturalmente trouxe a participação de muitas empresas que vivem de software livre atualmente. Sei que há pessoas que enxergam open source e capitalismo como coisas opostas, mas na minha opinião essa visão é míope. Open source é um modelo de desenvolvimento de software e oferta de produtos e serviços. A busca do lucro é o que move nossas empresas, e isso não é diferente para quem atua com software livre.

O surgimento das empresas profissionais open source foi importantíssimo para o amadurecimento das tecnologias e dos profissionais. Se o movimento open source continuasse restrito ao meio acadêmico, o nível de competição no mercado de software seria muito menor, e o avanço tecnológico teria sido bem mais lento.

Além disso, minha postura profissional é de tentar sempre entregar os melhores resultados para os clientes e para a empresa em que trabalho. Em algumas situações pode ser mais adequado usar open source, em outras pode ser necessário usar software proprietário. Temos que nos adequar às necessidades dos clientes, em vez de esperar que eles se adeqüem às nossas preferências.

No meu ponto de vista, empresas como JBoss e SpringSource contribuíram e contribuem muito no processo de profissionalização do software livre. A existência delas criou um mercado fortíssimo em torno do software livre, e eu só tenho a agradecer por isso.