Java Magazine 57

maio 27, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

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!


Atom: one format to rule them all?

março 3, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

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 😉


Microsoft também adere ao formato Atom para suas APIs

fevereiro 28, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

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 😉


RESTFox

fevereiro 26, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

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 🙂


Diversidade de tecnologias

fevereiro 11, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

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 😉


Jersey meets Abdera

fevereiro 6, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

Talvez os dois mais promissores projetos atualmente sendo desenvolvidos na área de web services Rest são o Apache Abdera e o Jersey. O Apache Abdera oferece uma API para manipulação de conteúdo no formato Atom, e é bastante útil para implementações baseadas no Atom Publishing Protocol. Já o Jersey é a implementação de referência da JSR-311, que mencionei num post recente aqui no blog.

Os 2 projetos são complementares, já que as funcionalidades de ambos não tem muitas interseções. Ontem o Marc Hadley, um dos principais desenvolvedores do Jersey postou sobre um desenvolvimento que ele está fazendo, usando o Jersey e o Abdera em um projeto de web services Restful. No post do Marc Hadley ele menciona que utilizou os recursos HTTP do Jersey (como mapeamento de URIs em classes e métodos e a capacidade de manipular diversos content-types) juntamente com as funcionalidades do Abdera de manipulação de recursos Atom.

Esta iniciativa foi muito bem recebida pelo James Snell e pelo Dan Diephouse (fundador do XFire), que são os principais desenvolvedores do Apache Abdera. O desenvolvimento destes dois projetos vem trazendo enorme amadurecimento aos web services REST e hoje já é possível desenvolver web services neste formato com grande produtividade e poder.

Claro que os projetos ainda estão em um estágio intermediário de desenvolvimento, mas é deles que virá a adoção mainstream com maturidade desta linha de serviços. Estou acompanhando continuamente o que está sendo feito nesta área, e o que já pude ver até agora é fascinante.

A propósito, os dois projetos são open source e os principais envolvidos fazem parte de empresas como a IBM, Sun, Mulesource, entre outras. O desenvolvimento de software open source é hoje em dia a principal forma de desenvolvimento da vanguarda da tecnologia mundial. As empresas já perceberam o sucesso do movimento e estão apoiando firmemente o mesmo. Não posso deixar de registrar minha profunda satisfação com isso. 🙂


Atom feeds for enterprise application messaging

janeiro 27, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

In the last months I have studied and worked a lot with web services in general, and more specifically the RESTful ones. I believe we are going through a fast maturation process in this area, and RESTful web services are becoming the preferred choice for many new implementations. Right in the thick of things in this field is the Atom Publishing Protocol. This is the blueprint solution for RESTful web services, and its adoption is growing fast, reaching much broader scope than just blog applications using the Atom Format.The Atom format and AtomPub protocol can both be used for many interesting purposes. This year I’m working on a big refactoring (actually a new implementation) of a widely used Globo.com application. This application (let’s call it Register) is responsible for the creation of new users and provisioning new services to them, among other features.

A nice concept present in the original development is the use of Application Connectors. Through these connectors, other applications get notified of events that happened in the Register application. An example is: when a new subscriber (a paying user) is created, a connector sends the notification to another application in order to create the subscriber’s mailbox in the company’s external mail provider. Another example is: when a user gets provisioned in the blogging service, another connector sends a notification to the blogger application, that does what it needs in order to create the user’s directory and quota on the file server.

Although i like this concept, it currently has some problems. This connector’s invocation is done explicitly by the Register application. The Register application knows that a new subscriber must receive a new mailbox, and it needs to call a given connector to do this. This is my biggest concern with the current implementation. I strongly believe that an application that creates users must not know anything about mailboxes. In the current structure, when a new application ABC must be notified of events in application XYZ, application XYZ must be modified to invoke a new connector. This doesn’t please me at all. Let me explain a solution that pleases me more 😉

To explain my idea, I’ll propose some examples involving Google and its services. As we all know, Google offers several different services, all of which can be accessed using the same Google account. When you register at Google, you receive a mail account. Let’s suppose that Google Register application sends a new entry to an Atom feed every time a new user is created. This way, every user creation is present on the Atom Feed. If an application (for example Google Mail) needs to be notified of the creation of new users, it just needs to subscribe to the Register’s Atom feed.

Let me propose a richer example now. Let’s say Google starts to offer some super cool software development services. If you’re a developer, you can ask them to give you a “development account”. This development account would give you access to a Subversion repository, a Bugzilla project and a MySql database. Each of these would be an independent service offered by them, subject to change at any given time. The activation of “development accounts” could also populate an Atom feed.

This way the Subversion, Bugzilla and MySql services could be subscribers of the feed, doing everything they need when a new development account is activated, in asynchronous manner. The application that activates the development account has no knowledge of any other services. If Google wants to offer new services such as a Maven repository or a Continuous Integration environment, no problem. The new services would just subscribe to the Atom feed and do whatever they need when a new account is activated.

If Google wants to offer a free development account and a non-free account with better features, there could be another Atom feed for the activation of the paying accounts or maybe updates to the same existing feed. The Register application would know only about registrations, and other components could be easily plugged and unplugged from this process, without modifications on the Register application. Ah, and worth mentioning… totally decoupled from any specific platform. I don’t know how to implement any kind of messaging more decoupled than that.

This is much much better than the way our Register application sends notifications currently. And I’ll be pretty happy once we manage to do this, it’ll be so cool!

By the way, these Google’s software development services would be awesome. My friend Bairos kindly provides me Subversion and Trac services, but he doesn’t have Google’s bandwidth 🙂 Let’s hope Google gets to know about this and starts offering these services. It’d be amazing!