Foi uma ocasião muito legal. Além de conhecer a rapaziada do grupo, eu também conheci a cidade de Fortaleza e já voltei para casa querendo retornar mais vezes ao Ceará. Do CEJUG eu conheci o Rafael Carneiro, Silveira,  Milfont, Tarso, Rafael “Foquinha” Ponte, Handerson, Igo, René, Paulo, Tales, Marum e mais alguns que eu esqueci o nome

Como eu já esperava o pessoal me recebeu muito bem e foi muito bacana conhecê-los pessoalmente. Além disso, já sou agora conhecedor de uma vasta gama de termos genuinamente cearenses   Diabéisso maxo!

Além de conhecer o pessoal do CEJUG, também tive a oportunidade de conhecer o Maurício Leal e o Kohsuke, ambos da Sun. Ambos são muito simpáticos e me passaram uma idéia legal de bastante coisa que está rolando na Sun.

O Kohsuke é também provavelmente o cara de mais prestígio técnico que já conheci, pois é nada menos que o criador do Hudson e um dos principais responsáveis pelo JAXB e pelo Glassfish v3. Inclusive uma das coisas mais marcantes da participação dele no evento foi trazer a todos o desejo de conhecer melhor o Glassfish e acompanhar as grandes novidades prometidas para esta nova versão. Uma das coisas que mais me interessou é a arquitetura modular com o Osgi. Eles estão apostando no Osgi junto com o Eclipse, e isto me trouxe a curiosidade de conhecer mais detalhes da tecnologia.

Bom, para destacar ainda mais a hospitalidade do pessoal, eles ainda me deram uma cesta recheada de ítens característicos cearenses. Gostei bastante dos presentes e quem quiser degustar a mais pura Ypioca aqui no Rio é só falar comigo

O evento em si foi bem legal e ainda teve uma banda animando o intervalo. Os coitados deram o azar de tocar logo na hora que o povo foi correndo comer, mas quem ficou assistindo curtiu bastante

Depois das palestras, bastante gente foi na confraternização e a bagunça lá foi até depois de meia-noite.

Para finalizar, eu gostaria de agradecer a todo o pessoal da organização lá em Fortaleza e também ao Gaúcho e ao Hildeberto por fazerem um evento tão legal e continuamente levar o CEJUG às cabeças. Esse tipo de comunidade traz uma enorme força ao mercado de software nacional e seria excelente que tivéssemos outros grupos com tanta energia como o do Ceará. Agradeço muito pela oportunidade e deixo meus parabéns à comunidade de software cearense!

Este ano o CEJUG completa 6 anos, e eu terei o enorme prazer de me apresentar no evento comemorativo dessa ocasião, na semana que vem.

O evento ocorrerá na próxima terça-feira, dia 16 de setembro, e promete ser muito legal.  Além da minha apresentação também teremos as apresentações do Kohsuke Kawaguchi e do Maurício Leal, ambos da Sun.

Para mim será uma ótima oportunidade para conhecer a rapaziada do CEJUG, do qual faço parte há alguns meses. Nunca é demais falar novamente sobre o excelente nível do grupo, que provavelmente é hoje o mais ativo do Brasil.

Além disso, não será nada mal conhecer a bela cidade de Fortaleza, onde já soube que o tempo está uma maravilha   Ê vidinha mais ou menos!

Fiquei muito contente com esta oportunidade e aproveito para agradecer ao Rafael, às empresas patrocinadoras do evento e à Concrete pelo apoio que estão me dando neste evento.

Eu me juntei ao CEJUG alguns meses atrás, depois de perceber o excelente nível do grupo e a vibrante comunidade de Java que existe no Ceará. Inúmeras vezes já elogiei o nível de envolvimento dos membros do grupo e o valor das discussões sobre software que rolam por lá. Me sinto bastante satisfeito por participar do grupo e trocar idéias e experiências com o pessoal.

Finalmente surgiu a oportunidade de conhecer a rapaziada da terra da tapioca e também a sua bela cidade. Estou certo de que a minha estadia por aí será muito agradável e aguardo ansiosamente por esta ocasião.

Neste evento eu farei uma apresentação sobre web services REST, mas um pouco modificada em relação às outras que já fiz sobre o assunto. Nesta apresentação falarei um pouco mais sobre como estamos utilizando REST no meu time para servir a requisições Ajax com JSON.

Meu time é responsável pelos sistemas de cadastro, autenticação e autorização de usuários da Globo.com e nós usamos REST para integrações Server x Server e também para comunicações Ajax com os clientes consumindo conteúdo JSON.

Além do meu time, a Globo.com já usa REST no Globo Vídeos e na nova plataforma de publicação de conteúdo do Portal.

Espero que o pessoal goste da apresentação e que minha ida ao evento seja tão proveitosa para vocês como para mim. Ah, e haja tapioca!

Os web services WS-* possuem o WSDL (Web Services Description Language), um artefato amplamente aceito que descreve de forma padrão os serviços da aplicação. Ao especificar no WSDL quais são os schemas XML dos documentos que serão trocados e a cardinalidade precisa de cada elemento, conseguimos garantir que qualquer cliente que entenda o padrão estabelecido será capaz de interpretar os documentos e comunicar-se corretamente com os serviços. Além disto, a maturidade deste padrão traz a vantagem de que já existem geradores de clientes em várias linguagens a partir de um documento WSDL.

Entretanto, WSDL (bem como muita coisa em WS-*) é complexo. Um ser humano que tenha que analisar um WSDL grande perderá um bom tempo para entender o que está descrito no documento. Já REST não tem uma forma padrão de especificar os contratos dos serviços.

Embora a versão 2.0 da especificação WSDL permita descrever web services REST, os principais projetos open source da área como o Apache Abdera, Google Data API, Jersey e o Mule não utilizam esta forma de publicação. Não tenho conhecimento de nenhum projeto publicamente divulgado que faça uso do WSDL 2.0 para descrever serviços REST, e a adoção desta capacidade é baixíssima (se é que existe).

O projeto Jersey oferece opcionalmente o WADL, que é uma forma de descrever serviços REST. Confesso que ainda não olhei o WADL para ver se seria interessante usá-lo. Pelo que sei, entretanto, a adoção dele também é muito baixa.

Existe também o documento de serviços do AtomPub, que é bem interessante. Ele é um documento simples que lista quais são as coleções disponíveis e a localização das mesmas. O documento informa também quais são os MIME types aceitos em cada coleção.

Eu considero interessante que a aplicação ofereça uma interface simples de consulta dos serviços disponíveis. Não é obrigatório, mas quando a aplicação tem uma certa quantidade de clientes é bem legal ter isso para facilitar.

Em dois projetos que eu trabalhei, eu implementei um Servlet simples que listava todas as URIs disponíveis na aplicação, quais métodos HTTP são aceitos em cada uma das URIs e além disso um exemplo de XML manipulado em cada uma das URIs. Isso foi algo que eu achei bom o suficiente, e não tão custoso. Normalmente a documentação de verdade dos serviços fica em algum lugar como uma Wiki, ou uma página qualquer com a descrição detalhada de como interagir com os serviços.

A questão principal é que quando você segue as boas práticas de desenvolvimento REST, os seus serviços ficam muito mais claros para quem precisa se integrar. Por exemplo, eu trabalhei em um projeto crítico de integração com o Google esse ano. Tive que usar várias funcionalidades da Google Data API. A API deles é REST, e encapsula os dados com o formato Atom. Eles não oferecem nenhuma interface semelhante ao WSDL, eles simplesmente têm uma página com a documentação dos serviços.

Como eles seguiram as boas práticas de implementação REST, eu rapidamente aprendi a utilizar a API deles. Os protocolos de comunicação REST são bem semelhantes, e mais simples de entender do que qualquer coisa com WS-*. Pouco mais de 1 hora depois de olhar a documentação deles, eu já estava conseguindo me integrar com eles, com os primeiros exemplos.

O Guilherme fez uma observação interessante durante a discussão disso na minha apresentação no Tech Talk. Quando você segue as boas práticas e implementa um protocolo conciso e claro, de certa forma podemos dizer que a implementação se “auto-documenta”. É algo que podemos traçar um paralelo ao que acontece ao utilizarmos Domain Driven Design. Aproximando a linguagem do código do domínio de negócio, facilitamos a compreensão da aplicação por pessoas que nunca a tinham visto antes. Uma boa arquitetura de web services declarativos (REST) fica muito mais clara do que uma arquitetura de web services imperativos (WS-*). Isto acontece porque com REST o que fica em destaque são os Recursos (que representam conceitos claros do domínio), em vez de Operações.

É claro que as pessoas ainda terão que ler um pouco da documentação, mas como os conceitos em sua maioria já estarão “no sangue”, as dificuldades iniciais são menores do que com WS-*.

O Felipe Gaúcho comentou no CEJUG sobre a capacidade de gerar clientes automatizados com WSDL. Embora isso seja verdade, no meu ponto de vista isso é meio que um mito. Não conheço ninguém que faça integrações automatizadas sem depender de seres humanos. A motivação disso é clara. Integrações envolvem regras de negócio, e ninguém que eu conheço faz negócios automáticos, sem definir as regras

Existia o mito de que as aplicações “descobririam” serviços automaticamente com UDDI e se virariam para fazer as integrações, gerando os clientes automaticamente. Embora isso seja tecnicamente possível, na prática isso pra mim é uma viagem que serviria mais para desenvolvimento de inteligência artificial do que para web services propriamente

Embora esta precisão do WSDL seja um ponto positivo, eu tenho a convicção de que a clareza que temos ao usar REST supera e muito as vantagens de termos geradores de clientes automatizados. Quanto a WS-* x REST de uma maneira mais geral, tem uma frase que eu gosto de utilizar. WS-* é apenas overhead a não ser que você tenha informações relevantes nos seus cabeçalhos SOAP. Se você nunca se preocupou MUITO (veja bem, MUITO) com o que está indo nos seu cabeçalhos SOAP, provavelmente um protocolo REST seria mais interessante.

Tem uma opinião a respeito disso? Estou ansioso para conhecê-la!