Netbeans growing stronger

maio 12, 2008

Atenção, este blog foi migrado para:

During several years I’ve been a pretty happy Eclipse user, rarely feeling the need to use anything else. We know there are plugins for many many things, and a lot of development tools are Eclipse-based right now. The editor is awesome, and so are the refactoring tools. The support for web app development is also very nice. Eclipse supports a wide set of frameworks and technologies, and it’s not only aimed at Java development.

Why would someone even look at anything else, having such a great tool? Well, it turns out that our field is evolving really fast, and it’s very hard to follow this current pace, even for the most dedicated and passionate ones. Currently there are several technologies evolving very fast, and they are meaningful to a lot of enterprise developers. The rise of the JVM’s dynamic languages is crystal clear. Strong is also the growth of RESTFul web services. I’m personally very interested in both fields.

I’m currently using REST (lately with Jersey) for a lot of integrations between applications. The power it gives me is really nice, and I’m improving my developments each new month. I have also studied Groovy/Grails recently and really liked it. I wanna try JRuby on Rails sometime in the next weeks, to see what it offers and check how it compares to Grails. If you’re a Java enterprise developer, I’m sure you’re following the growth of these nitty things.

But where does Netbeans enter this talk? Well, Netbeans is doing a great job supporting these new technologies, and it’s way ahead of Eclipse in this field right now. Have you seen how easily you can develop RESTFul web services with Netbeans 6.1? Jersey support is great, very productive. The support for JRuby on Rails and Grails is also present, in a much more advanced state than Eclipse’s. Netbeans is doing a much better job than Eclipse regarding Web Services and JVM languages right now.

Swing development in Netbeans is very nice since version 5.0 (with the release of Matisse), and developing for mobile devices is also easier in Netbeans. Currently I don’t develop swing nor mobile applications, so this doesn’t really affect me.

However, I develop many RESTFul web services. And I wanna use more and more the JVM’s dynamic languages. Ignoring Netbeans is not a clever idea right now.

I still find Eclipse’s interface and editor much better than Netbeans’s. I also know a lot of Eclipse’s shortcuts and know very few in Netbeans. SWT is also faster than Swing, so Eclipse is faster than Netbeans. But considering what I said, I’m leaning towards the use of both IDEs at the same time. Since our machines are now much better equipped with RAM, I can have them open at the same time and also a couple of servers, with no memory shortage.

My Eclipse days are definitely not over, but now he’s gonna divide my attention with Netbeans 🙂 I hope I can become as productive with Netbeans as I am with Eclipse, even if it takes a few weeks. My first wish would be the Eclipse’s Quick Fix (Ctrl + 1) avaiable in Netbeans. Even without it, I’m sure my usage of Netbeans will certainly grow, and think this competition between the IDEs is very good for us. Let Eclipse Ganymede come!


Query strings in RESTFul web services

abril 5, 2008

Atenção, este blog foi migrado para:

I said before that I don’t like query strings in RESTFul URIs. You cannot cache the results in the web server and in many cases they lead to a poor design of your URIs.

However, there are cases where query strings are useful and make sense. In the project I’m working right now, we have an asynchronous queue which several server instances consume periodically. This queue has events that must be processed, and each event belongs to a given user. Each user may have several events in the queue.

We have this queue of events that must be processed and we register them in another list when they are successfully processed. When an event is processed, he goes to the “processed” list if everything goes right or he stays in the queue if something gone wrong. In the queue we register how many times we tried to process each event.

In my team we have an application that helps us manage our infrastructure. This application does many things that we previously needed to ask to the operations team or DB team. Something very desirable is to be able to check how the queue is going without needing to check server logs or the database. So we’re adding some features in the management application to help us check the queue.

Ok, now let’s talk about the RESTful services. We’ve implemented some services that access the queue. One the of services allows us to check how many events are still in the queue with at least N tries. For example, how many events are pending with at least 1 try?

What’s the Resource here? In my opinion the resource is “Pending event”. Considering this, I would access this resource doing GET /event/pending. Ok, but doing GET /event/pending would probably give us the whole list of pending events. I want pending events with at least 1 try. How can we do that? We could do a GET /event/pending/1, and it would work. However, this URI is bad, very bad. If I didn’t know what this service was about, I’d probably say this URI returns the first pending event according to some order. Probably it would be the oldest or newest one.

So how do we form this URI? We could also have a GET /event/pending/tries/1. This would indeed be much better than the first URI, but I don’t like it either. My resource is “Pending event”. Pending events with at least 1 try are still just pending events for me. What I want is just to filter the pending events. So, I ended up using GET /event/pending?t=1. “t” in this query string stands for “tries”. I could also have used GET /event/pending?tries=1. As a matter of fact, I think supporting both is nice. It would be similar to command line options in Unix applications.

Now, let’s say I want to know the pending events of a given user. Looking at the previous URI, You might say GET /event/pending?u=123 or GET /event/pending?user=123. But in this case, I wouldn’t use query strings. The best URI in my opinion is /event/pending/user, and that would lead to GET /event/pending/user/123. What’s the difference here? I consider the “User” as a meaningful thing. It’s another resource. However, “number of tries” for me is just a filter. I don’t need to know anything about a specific try, so it’s just a filter in this case. Another similiar filter would be “Pending events created before today”. We could have another query string parameter to filter events by creation date. Something like GET /event/pending?c=03/04/2008 or GET /event/pending?creation=03/04/2008.

So, I changed my mind a little bit about query strings. They are indeed useful in some cases, such as this example. They are good to filter results. Filter by something that it’s not a resource. To decide our URIs we must always think of what’s really a resource in our application, and what’s just a filter. Such as in the world wide web, URIs identify Resources. After deciding what’s a resource and what’s just a filter, we can design our URIs much better. Meaningful URIs are among the most important things in RESTFul web services.

Atom: one format to rule them all?

março 3, 2008

Atenção, este blog foi migrado para:

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 😉

Java annotations abuse

fevereiro 21, 2008

Atenção, este blog foi migrado para:

I know Java annotations are a very controversial subject, and there are lots of different opinions regarding them.

In a general manner, i like annotations. Annotations placed on classes and methods are nice, they help a lot without much damage. A good example of well used annotations in my opinion is the Java Persistence API. It reduces a lot of the code you’d need to write and doesn’t polute things too much.

However, placing annotations inside method arguments, such as in JSR-311 (first place where i saw it) starts to really mess things up. Here’s an example of the use they propose:

public class WidgetList {
WidgetList getDiscounted() {...}

Widget findWidget(@UriParam("id") String id) {
return lookupWidget(id);

The @UriParam is the one that really bothers me here. I’m sure it must serve a good purpose for the JSR, and it probably makes some stuff easier. However, it’s unquestionable that annotating this much starts to polute the code beyond the acceptable limits. In such a short piece of code we saw 5 annotations.

I’m not saying we should go back to XML files. I really prefer annotations over XML when they are used over classes and methods, much like JPA does it. However, as many other things, annotations can be misused, and in this JSR 311 example, i think they misuse them. I just hope this trend doesn’t get stronger, because i think Java would get uglier with this. Just keep the simple annotations please 🙂

Google Data API

fevereiro 21, 2008

Atenção, este blog foi migrado para:

I’m currently using Google Data API at work. This API offers RESTful interfaces for several Google services, such as Calendar, Picasa, You Tube, Blogger, Google Documents, among others. There are also client libraries for Java, C# and Python, but these are actually tools to facilitate, rather than new interfaces. All client libraries access the RESTful interfaces, so by all acounts the API is RESTful.

What I’d like to comment is how easy it was for me the to get up to speed with the API. There are several pages explaining the API’s features, the URIs, their use of HTTP method, return types, etc. Their design is pretty much compliant to all REST best practices (although they do use some query string parameters ocasionally). Being very familiar with this kind of web services, most of what I did was looking and saying: “Ok , this is how i expected it to be”. And after less than one hour I was ready to begin using the API properly.

Worth noting is that there were no “Interface Document” to look at. Not anything similar to WSDL or any other IDL. What was there was just a simple and RESTful API that was pretty easy to use after you knew what the resources were and which operations they support. Several pages describing their protocol and the XML entities they use were enough for me to know how I was supposed to integrate with a reasonable amount of their services.

I don’t even want of to think of how would it be if they had WS-*. Just to read the WSDL documents would take me more time than to read all their RESTful documentation. There would be a lot of operations and messages described in their WSDLs, and it’d be a massive reading to get the grasp of the API.

Fortunately Google (the most powerful web company) is embracing a RESTful design and it should probably take many other companies with it. They’re also supporting the use of Atom and Atom Publishing Protocol, so many nice things should keep coming. Apache Abdera is already integrating Google Feed Server code, and hopefully we’ll be able to use Abdera for most of Google’s services.

Very very nice! By the way, I took a good look in the source code of Google Data API and it’s very well implemented. They have a very interesting approach to manipulate feeds and entries. It makes it very easy to model a lot of stuff using just feeds and entries. It was an inspiring code inspection and I’m thankful Google also embraces open source 🙂 These guys are good!

Atom feeds for enterprise application messaging

janeiro 27, 2008

Atenção, este blog foi migrado para:

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 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!

Elixir of productivity boost

janeiro 20, 2008

Atenção, este blog foi migrado para:

Since I returned from my trip to Argentina and Chile, I’ve been pretty busy at work and when I get home at night. I’m writing an article on web services (more on that in February…) and got a small freelance project to do.Sometimes it’s kinda hard to produce well at night after a tiresome day at work, but a long time ago I discovered my powerful elixir of productivity at night 🙂 For those of you who do not know me personally, although I’m rather eclectic regarding music, I’m a brave heavy metal fan at heart 😉

When I must start high octane mode at 9 PM, I usually start listening to a power metal set, composed mostly by some finnish bands I love. This year, I’ve been listening to Sonata Artica, Nightwish and Stratovarius most of the time. These bands have some very addictive songs, and the high speed drums combined with the talent of their singers (as for Nightwish, I’m refering to the Tarja Turunen epoch) give me my much needed energy.

Tony Kakko, Tarja Turunen and Timo Kotipelto are really great singers and exceptional live performers.Unfortunately, I never had the chance of going to a Sonata Arctica gig, but I went to Nightwish and Stratovarius gigs in the past and it was awesome. I really like to listen to their live performances, and fortunately You Tube offers a very rich collection of everything you want to listen, so I recently created a playlist there.

For those of you who want to make use of my powerful elixir of productivity boost, the playlist can be accessed here. Long live heavy/power metal! Have fun!