Monday, July 28, 2008

Data Conversion Libraries 'R' Us

I've noticed a good chunk of traffic towards this blog is from people looking for help making their relational data (or Java classes) into XML/JSON/(insert Web-friendly format here), and vise versa. Well, this entry's for you.

Are you developing a Web application that requires object serialization, and don't want to write custom mapping files for every object? Have a database you want to access in an object-oriented way? Well, you're in luck! There are plenty of solutions that will do most of the heavy lifting of these processes for you. I will quickly introduce a few of them - Hibernate, Middlegen, XStream, and JAXB - with which you can rapidly access your database as objects, serialize the data to XML documents or JSON representations, and send it around the Internets at will.


If you want to use XML or JSON as your translated medium, XStream provides automatic Object -> XML (and back again) mechanisms, requiring only a JVM and some knowledge of Java. In my experience with XStream, it is a very good answer to a problem that otherwise took a lot of manual effort to do correctly. Best of all, you typically don't have to create any custom mappings, so if you're in a pinch, this will provide a big bang with little effort. Also worth mentioning is that XStream has a very impressive performance profile, so if your server has high throughput, XStream should not be a bottleneck.

Hibernate and Middlegen

If you have your data in a database and want to move it to Object-land, I'd advocate a classical solution: Hibernate and Middlegen. Most of you might know about Hibernate, but if you don't it's an "object/relational persistence and query service", or a service that will transition your data between its persisted state to handy Objects, based on queries you specify and mapping files you provide. The rub is in the generation of the mapping files, as it is not a task I imagine anyone enjoys. That's where Middlegen comes in; it will auto-generate mapping files based on the structure of your database, and for the most part does a fantastic job of it. It isn't perfect, but it will at least yield a result that you can tweak to your needs.

On the useability front, Middlegen can be a bit of a pain to set up and plug in, but if you have a lot of data to deal with (it generated over 100 mapping files for my case), it's worth it. For what it is, Hibernate is pretty easy to set up and run (although it has a LOT of dependencies to clutter up your classpath). The biggest issue I've come across is its performance. At first use, Hibernate will probably make you cringe. The memory footprint can get ludicrous very quickly, and typically in the amount of time it takes to bootstrap I can build an Ark. But once it's up and running on a machine with sufficient memory, it will perform quite well, querying the database and yielding a list of objects to play with in about the time it would take to do a raw SQL query. And if there are still sufficient performance issues, the cache-control mechanisms Hibernate allows for can give a big boost to your application (either minimizing memory usage or increasing throughput), depending on your traffic profile.


If your client application runs inside a Java container, or if your server-side data consists heavily of XML documents, JAXB provides a way to take these documents and unmarshall their data into Java objects. I'm not going to lie and say I've used it, read anything more about it than in a few articles, or even say it looks painless to use, but I've had it recommended to me from a few reliable sources, and figured I'd give it a mention.

Have some better or alternative methods? Used anything I've mentioned above? Please share it in the comments section!

Friday, July 25, 2008

GWT and RESTlets

I'm back, with some big news!

RESTlet ported to GWT!

I have been busy with a large-scale, enterprise AJAX Web application, and I'm happy to say I've had to write at most 200 lines of Javascript; instead, we have about 80,000 lines of Java. Most of you probably know why ... we're using Google Web Toolkit (GWT) (+ RESTlets), and thought I would share my love for these libraries. (Before we delve deep into my ramblings, I'd like to point out there other libraries that rival RESTlet's fantastic-ness, such as Jersey, but I've not used them extensively enough to write about them, so feel free to post your links to other blogs!)

If you haven't heard of GWT or just haven't taken the time to check it out, you really, really should [ ]. In short, Google developed a compiler that creates Javascript bytecode from Java source, so you develop your Client-side code just as if you're developing a Java app (don't worry, custom Javascript can be invoked using JSNI), and Google does the rest of the work.

If you're going to build both the client-side and server-side bits, GWT has some built-in support for you. It provides RPC mechanisms, as well as ways to make plain ol' HTTP requests. First up: RPC! Simply explained, an RPC-based application is built using just a few pieces and parts - an interface so the client knows what methods it can invoke and an implementation of these methods on the server. Having used it, though, the RPC is a bit arduous to maintain, clunky to build, and can be slow as molasses. But it works, has the benefit of making the client-side code easy to read, and methods more intuitive to invoke.

Now, if you want to provide server-side functionality via HTTP requests instead of RPC calls, the RequestBuilder class is what you want. It has a simple and relatively robust API, but has its drawbacks. If I had to try to pick a fight, I'd say the drawbacks are that it does require a bit of knowledge about the lower-level workings of HTTP requests (e.g. header syntax), and doesn't provide a quick way to get XML from the Response object in a Document format, but there aren't any really pressing issues that I've encountered.

So enough about GWT - what is this RESTlet stuff? Well, it's based on a particular architectural style, developed in the wonderful world of Acadaemia (don't run away now): Representational State Transfer (REST). It's just a way of designing how to manage and access resources, and once you figure it out, you'll notice a lot of the Internet basically works this way already. Let's say you're building a store that sells T-shirts of many colors. A RESTful way of modelling your store-front would be to provide the resources of your store, e.g. the T-shirts, in a representational way. So to see a representation of all T-shirts sold at the store, one might visit the url To see a representation of all blue T-shirts, one could visit /storefront/tshirts/blue. To visit the cart, one could go to /storefront/cart. These resources can be delivered as XML, XHTML, JSON, binary, plain-text ... you name it. Each URL basically represents a resource and ways to get to other resources, if applicable. Intuitive? I tend to think so.

By the by, my colleague explains it well (i.e. better) in non-example-based terminology, if you'd like to see it go here:

In any case, REST is a wonderful way to expose resources and functionality to your client code in an intuitive way, and the greatest of all is that it highly decouples your client and server code bases, so if you deliver your resources in a client-independent way (e.g. XML), you can show off your resources in many different ways.

If you'd like to create a GWT + RESTlet application, check out the RESTlet-GWT module [ ]. If you give it a try let me know how it goes! I've had such good luck with it I'm rather skewed towards it, but I'm still a bit of a n3wb Web app developer, and I'd be very interested to know what your opinions are.