Bruno Pereira

Well, as I said recently, we want to use a registry to keep URIs of our services and also some configurations that are currently in properties files.

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.

O Bill de hÓra publicou um post sobre um assunto que me interessa enormemente. Ele comentou sobre a dificuldade de se projetar boas APIs e protocolos.

Para quem não o conhece, o Bill de hÓra foi o co-editor da RFC do AtomPub, o protocolo de publicação do formato Atom. No post ele comentou sobre a dificuldade de elaborar um bom protocolo de comunicação (no caso o AtomPub). O trabalho demorou mais de 2 anos para ser concluído, e neste 2 anos não contam o tempo no qual o Joe Gregorio (o outro editor da RFC) já estava trabalhando no protocolo antes.

Uma observação que ele faz é que é difícil encontrar indivíduos capazes de projetar boas APIs, e bem mais difícil é encontrar indivíduos capazes de projetar bons protocolos de comunicação. Algumas pessoas dizem que essas habilidades (projetar APIs e projetar protocolos) são de certa forma opostas, o que implica que seria especialmente difícil encontrar pessoas com habilidade nas 2 coisas.

Ler esse post foi motivante e inspirador para mim.  Neste exato momento eu estou fazendo as duas coisas simultaneamente. Meu time é responsável pelo sistema de cadastro de usuários e autenticação da Globo.com, entre outras coisas. Esse sistema é provavelmente o que possui mais clientes internos na empresa. A implementação original utilizava EJBs para comunicação remota entre clientes e o servidor, e permitia apenas clientes Java.

Estamos progressivamente saindo dessa estrutura. Estamos implementando novas interfaces e clientes que usam serviços REST na comunicação, em vez dos EJBs. Isto está sendo feito de forma progressiva porque nenhum Product Owner daria alto valor de negócio para uma migração dessas, exceto em situações extremas (que não são nosso caso).

Pois bem, nesta migração eu estou atuando nas 2 frentes que o Bill de hÓra classificou como desafiadoras. Estamos modelando os serviços REST e o novo protocolo de comunicação. E estamos também implementando uma API Java para realizar as operações através deste novo protocolo.

Sem dúvida esta migração é desafiadora. De fato não é fácil elaborar um bom protocolo e uma boa API. Porém, isto também motiva demais. Quem acompanha o meu blog já sabe do meu apreço por serviços REST. Assim, este trabalho atual tem sido ótimo para conseguir explorar inúmeras situações envolvidas neste tipo de comunicação.

Para minha sorte, pude contar com alguns pontos facilitadores. Na elaboração do protocolo, o conhecimento do AtomPub ajuda muito. Eu já conheço bem esse protocolo e tinha desenvolvido serviços REST em alguns projetos, então essa parte da empreitada ficou muito facilitada.

Além disso, o conhecimento da API Java anterior do projeto traz várias idéias que podemos explorar. Algumas decisões na API anterior foram muito boas, e outras trouxeram alguns problemas. Eu não participei da implementação original do projeto (isso foi em 2004), mas após trabalhar no projeto por bastante tempo, consegui vivenciar bem os problemas dela. O principal era o alto acoplamento entre o servidor e os clientes, então isso é o principal ganho que pretendemos ter com essa nova implementação baseada em REST.

O outro ponto facilitador é estar no mesmo time que o Silvano, certamente um dos melhores caras que já conheci tecnicamente. Nós temos visões complementares sobre a arquitetura e a implementação. As idéias que colocamos na prática após as freqüentes discussões são muito superiores às que eu ou ele seríamos capazes de desenvolver individualmente. Com a liberdade de decisões técnicas que temos na Globo (principalmente após a adoção do Scrum), conseguimos evoluir nossas aplicações progressivamente, sempre avaliando pontos positivos e negativos das decisões anteriores.

Após ler esse post do Bill, tive uma dimensão melhor da grandeza do desafio que estamos tendo agora. Isto traz ainda mais motivação, e não abala a confiança. Tenho a mesma sensação que Isaac Newton teve ao dizer que “se ele pôde enxergar mais longe foi porque se apoiou nos ombros de gigantes”.

Quando estamos trabalhando freqüentemente com padrões e tecnologias abertas, temos sempre essa vantagem. Viver no mundo open source é se apoiar sempre nos ombros de gigantes, e então qualquer desafio fica muito mais suave e a nossa confiança aumenta. É por isso que eu amo o que faço

Já está nas bancas a edição 57 da Java Magazine. Nesta edição saem 2 artigos meus sobre o formato Atom.

O artigo maior apresenta o formato Atom e o seu protocolo de publicação, o AtomPub. Além desta apresentação, tentei indicar alguns pontos importantes que tornam interessante a sua adoção no desenvolvimento de serviços REST.

O artigo pequeno é no formato “Quick Update” da revista. Nele eu analiso a adoção do formato Atom em serviços REST e destaco os principais aspectos a serem considerados para se decidir pelo uso ou não do Atom.

O Atom e o AtomPub são muito interessantes, e mesmo que você não use diretamente o formato, tenho certeza de que ele te trará boas idéias para a implementação de serviços REST. Have fun!

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

Depois de o Google passar a usar APIs RESTful com o formato Atom, agora é a vez da Microsoft começar a usar este formato. Ontem a empresa anunciou que as APIs do Windows Live serão RESTful e farão uso do formato Atom.

Após alguns anos investindo pesadamente em web services WS-*, parece que a gigante de Redmond está lentamente mudando sua forma de pensar em serviços web. É claro que durante um bom tempo eles ainda vão defender ferrenhamente o uso da pilha WS-*, pois eles não querem jogar fora os investimentos nessa área para a plataforma .NET. Contudo, é sem dúvida interessante ver que talvez o maior defensor de WS-* está mudando de direção, embora ainda não de forma integral.

Como eu já havia comentado algumas vezes, parece que a adoção de web services REST para diversos fins vai mesmo crescer rapidamente e ocupar um bom pedaço do espaço anteriormente ocupado por WS-*. E mais, eu acredito que os serviços REST vão crescer muito como mecanismo de integração de sistemas e plataformas. É bastante provável que o uso de integrações com EJBs e outras tecnologias que te prendem a uma plataforma específica caia de adoção. Especialmente em aplicações de internet, tenho convicção de que veremos um espaço cada vez maior sendo ocupado pelos serviços RESTful e que esta passe a ser a forma número 1 de comunicação entre diferentes aplicações.

O formato Atom tem muito a ver com esse crescimento, pois além do formato ser excelente para manipular conteúdo web, o protocolo AtomPub é um belo blueprint de implementação REST. Sempre que eu estou tentando definir um protocolo de comunicação REST e fico um pouco em dúvida sobre a melhor forma de fazer alguma coisa, minha primeira referência é o AtomPub. Estudar como eles resolvem problemas comuns no desenvolvimento REST te dá uma visão muito boa das opções disponíveis. Você já começa de um ponto de partida muito bom, e fica bem mais fácil elaborar um protocolo conciso e coerente depois que você conhece o AtomPub.

A propósito, quem quiser conhecer mais sobre implementação de serviços REST, recomendo fortemente a Java Magazine de Abril. Um certo sujeito vai publicar um artigo prático bem interessante sobre implementação destes serviços

Eu tenho trabalhado bastante com web services REST ultimamente. Para testar meus serviços, a forma padrão que eu uso para testar é criar alguns testes unitários que montam as requisições e recebem as respostas com o commons-http-client.

O commons-http-client é perfeito para testes unitários, e para uso por uma aplicação. Para testar manualmente, entretanto, eu gostaria de algo mais prático. Pensando um pouco nas características dos testes que eu faço, um plugin do Firefox seria a ferramenta perfeita. Eu precisaria criar requisições HTTP com qualquer método (além de GET e POST) e especificar o corpo da requisição (onde for o caso), assim como alguns headers também.

O caso de uso principal deste plugin seria a criação de requisições GET, POST, PUT ou DELETE nas quais eu pudesse especificar os XMLs do corpo (aplicável apenas para POST e PUT) e pudesse conferir a resposta HTTP completa, incluindo todos os headers. Isso já seria uma facilidade enorme. Para refinar, deveria ser possível guardar alguns templates de XMLs de entrada. Um exemplo claro que me vem à cabeça é um template de XML no formato Atom, que poderia ser usado para requisições à Google Data API, entre diversos outros serviços que já utilizam o Atom como formato padrão de documentos.

Eu dei uma procurada boa e não achei nenhum plugin que fizesse nem uma parte disso que eu quero. Caso vocês conheçam alguma ferramenta do gênero (mesmo que não seja plugin do Firefox) por favor me avisem. Se eu não descobrir nenhuma ferramenta que ofereça isso ao menos de forma parcial, pretendo desenvolver eu mesmo esse plugin para o Firefox. Eu ainda nem comecei a fazer nada desse plugin, mas já gosto do nome RESTFox. Vamos ver se sai algo bacana daí… eu nunca desenvolvi plugins para o Firefox, mas me parece que este será o primeiro

Eu tenho postado com alguma freqüência sobre o que vem acontecendo no desenvolvimento das tecnologias dos web services Restful.

Este fim de semana o James Snell implementou um adapter do Apache Abdera para o CouchDB. Este adapter permite que se consiga facilmente implementar um armazenamento de dados no formato Atom com uso de uma instância do CouchDB.

Como eu já mencionei anteriormente, o Abdera oferece uma API para manipulação de conteúdo no formato Atom e a realização de operações do Atom Publishing Protocol. Já o CouchDB é um banco de dados orientado a documentos que é escrito em Erlang e foi projetado para extrema escalabilidade e permite fácil instalação em servidores com múltiplos núcleos ou em clusters de máquinas.

Em vez de utilizar tabelas com colunas (como os bancos de dados relacionais), o CouchDB armazena os documentos em formato JSON e disponibiliza como interface uma API Restful, com clientes já implementados em várias linguagens, como Javascript, Java, PHP, Ruby e Python.

Acho que isto expressa muito bem o horizonte que vem se formando. Em vez de pilha de tecnologias e protocolos proprietários, temos diversas tecnologias e plataformas diferentes conseguindo se comunicar através de HTTP. Um projeto open source Java que manipula conteúdo Atom já disponibiliza com facilidade um mecanismo de integração com serviços REST que manipulam dados em formato JSON.

É impressão minha ou estamos de fato vendo rapidamente uma mudança radical de abordagem na vanguarda da tecnologia? A mesma IBM que antigamente dominava de forma absoluta todo o mercado de hardware e software com soluções proprietárias agora patrocina diversos projetos open source e mantém sua elite intelectual trabalhando nestes projetos.

Soluções open source estão liderando várias frentes de desenvolvimento e com isso rapidamente surgem integrações entre componentes feitos em diferentes linguagens e plataformas. O conhecimento não está mais guardado a 7 chaves, e sim discutido abertamente por uma comunidade que aceita qualquer um com capacidade para agregar idéias boas.

A criatividade e a iniciativa individual nunca tiveram tanto poder, e isto é fabuloso. Com isso, claro que a versatilidade e o conhecimento diversificado ficam muito valiosos.

Hum… maybe it’s time for me to fight my disgust for Javascript and start developing something nice including JSON