Monday, April 28, 2008

The Internet: An Alternative to GWT's RPC

This blog is aimed at software developers currently or considering using Google Web Toolkit (GWT), and assumes you have some prior knowledge/background. I do not aim to be technical in this blog, but rather, simply expose the idea and provide insight to those loathing particular programming paradigms.

Google's Google Web Toolkit (GWT) has make remarkable breakthroughs in allowing Java developers to easily create websites and web-based applications with little concern about cross-browser issues. As a software developer fitting this niche, I must say I am more than happy with what GWT provides.

That said, one of the biggest complaints about GWT is it's Remote Procedure Calls (RPC). In a nutshell, your client calls a function through an interface which the server interprets, executes, and returns a Java representation of results. The actual process is somewhat annoying to implement, can be somewhat clunky, and can have the speed of the DMV lines at the end of the month. Ok, so I'm exaggerating a bit, but it's nuiances were enough to me to choose to never go back to RPC. In addition, I don't think my server should be returning me a Java Object. If I wanted to access this outside the context of my GWT application (hey, these "crazy" things may happen), I know Internet Explorer probably can't render it too well -- it has a hard enough time with HTML (zing!).

Allow me to re-introduce the concept of REST.

Representational State Transfer (REST) is an architecture style that, well, kinda does what it says. In the context of Web Apps, it defines how we define, locate, and access resources. If you want the whole scoop, I've got reference links at the bottom. For this exercise, you just need to understand resources and representations.

A resource is the conceptual target of a reference (the reference being, generally, a URL). A file, for example, could be considered a resource. The file's representation can be a number of things, but examples are HTML, XML, GIF image, basically what the user sees. In short, it represents a resource in some meaningful way. For this exercise, let's go with XML as our default representation (it will become painfully apparent why soon).

With RPC, using a method to retrieve some data (a Representation, perhaps) is the standard means. There is a RESTful way to do this a well, and here's the kicker: it's a basic building block of the Internet! The standard CRUD (Create, Read, Update, Delete) operations are already represented as HTTP PUT, GET, POST, and DELETE, respectively. I'd argue that just about anything you'll need to do with a web application can be covered by one or a combination of these functions. I'm not going to get technical today but take my word for it.

Enter RestLet. A lightweight, open-source Java API that acts as a catalyst in developing Web Services in Java to handle ANY general HTTP request. A request from, say, our Web-based GWT application! RestLet employs the principles of REST, transferring representations from the server to the client upon request. Assuming we use XML Represenations, we already have a means of parsing and interpreting these representations client-side ... AJAX, which is at it's core, GWT.

Now, we have a generalized API to program to and access data from. We can use GWT to make requests, but now JSNI, JSP, PHP, even standard HTTP requests are respected. We have a portable server to interpret our requests and the responses (XML representations) are immediately parsable, even by IE (zing!).

In short, employing the principles of REST to ANY web app is incredibly beneficial for a number of reasons that I'll leave to the avid reader to convince themselves of. Roy Fielding has spent plently of time stating things and I don't need to use more. RestLet, an open-source project provides a well-thought out means of utilizing this architecture. And with this, you can finally give that RPC code a REST.

I wanted to use this blog to simply introduce the concept of REST within the context of GWT, how it can be leveraged by AJAX, and how it can be used as an alternative to RPC. If there's any interest, I'll do a follow-up blog or blogs that will delve into the following topics:

  • Current Open-Source Applications using REST/RestLet and GWT.
  • Open-Source Solutions made to speed up XML processing and leverage REST.
  • Creating a RESTful Web Server
  • RESTful References and Why They're Essential

This is all information you can dig up yourself, but I'm happy to share. REST and RestLet, of course, aren't the only way to get outside the RPC box, but, from my experience, it works efficiently, encourages robust code, and, most importantly for me, let me say bye-bye to RPC.

To close, I want to say that I don't profess to be a definitive authority on this, and I'm still learning new things everyday. I look forward to any feedback on this you may have, and any other out-the-box ideas.

Carl Scott
Software Developer, Solertium Corporation
View Carl Scott's profile on LinkedIn View Carl Scott's ohloh profile



  1. I reed your article and i agree with you that RPC programming in GWT is somehow laborious. In my experience, the big problem of AJAX is the "X" which represents XML. It is easy to read by human beings but it es very expensive to read for browsers (in terms of cpu load and memory).

    So, whatever you want to optimize with a REST . Please keep in mind not to transfer XML object representations. Transmit something that is easy to read BY BROWSERS without additional plug-ins or special xml libraries. Otherwise, you can make better results by using other client GUIs. GWT is made and opimized for the standard web client (the browser).

  2. Oh I agree, within the context of GWT where there is a known intermediary, you can have your server return XML representations for GWT to do interesting things with.

    RestLet's Resource implementation utilizes Variants, which you can use to change the representation based on what you want, so you can return HTML, XML, etc. representations of the same resource based on the request. This comes in handy when you'd want XML reps for GWT, but, in the case you pointed out, be able to have a readable rep outside that context.

  3. Hi Carl,
    we are VERY interested in reading more about RestLet and GWT.

    I think that a problem the GWT community currently has is generating intelligent stress-tests for their GWT applications.

    You just can't affort to run a firefox image for each user you want to simulate, and on the other hand you can't just playback pre-recorded RPC calls because you want to generate requests according to your own criteria and logical sequence...

    The best solution for us would be a proxy-generator creating for us a pure java proxy from the GWT service specification: this way a java application might easily generate all the RPC calls by simply invoking the proxy methods.

    Unfortunately, after a short survey , it seems that such a proxy generator does not exist.

    So this is where our interest in RestLet comes for: maybe we can "open up" our GWT backend so that it can be used by both the GWT (JS) client running in the broswer AND by any other authorized application (including our java stress test).

    Could you please provide more info in GWT / RestLet ? Thanks.

  4. Valid points, and yes I think that a proxy generator is a good ways away if it's even being considered by the dev team. Really, the whole idea behind the implementation though it to decouple the unnecessary relationship between GWT client and server. You have a RESTful, independent client running and GWT just makes calls to the server.

    I'll be doing another blog soon with more details on this, so check back soon. Thanks for the read!

  5. Hi, nice article.

    Do you use GWT-REST? Would you recommend it?

    As an alternative to RestLets, I've been using Jersey, and like it so far.
    If you assemble your resource with JAXB, it is just a question of a single annotation to produce JSON or traditional XML representation.

  6. Thanks for the read and recommendation! I actually do not personally use GWT REST, though I have delved into its code and spoke with the developers. It seems usable, but it also looks like there a bit of unnecessary bloat in there for most applications. If you've got a good grasp of REST principles and you plan on reeeally utilizing its full functionality, try it out. Once I get client-side, though, I don't find myself in need of a REST wrapper. But again, the more you utilize more advanced functionality, the more it seems to be useful, but I have not personally used it.

    I must say, I'm a fan of RestLet, but I'll given Jersey a look too -- thanks again!

  7. Hi Carl,

    Thanks for the nice post and comments! We have great news on the Restlet + GWT front... :-)

    With the help of Rob Heittman, your CTO at Solertium, we have just released a port of Restlet to GWT.

    Best regards,

  8. Impeccable timing, I just heard the news and did some reading up on it and some other REST technologies:

    Thanks for the time in reading, much appreciated!

  9. Who knows where to download XRumer 5.0 Palladium?
    Help, please. All recommend this program to effectively advertise on the Internet, this is the best program!

  10. If you guys are looking for a resful aproach to doing GWT based RPC, then take a peek at the RestyGWT project. RestyGWT is a GWT generator for REST services and JSON encoded data transfer objects.

  11. Hmm, could be an interesting framework as we begin to use JSON more. Will certainly keep this in mind, thanks for the recommendation!

  12. Just don't use Restlet's GWT edition, it made my GWT app like 30% bigger. It's a huge spaghetti dish, all units intercoupled, lot's of hardcoded data (mime types). I found it much easier and efficient to use GWT's overlay types + it's HTTP client API + gwt-dispatch ( It's build for RPC but it can be used with REST as well after custom service impl.

  13. Giving relative numbers doesn't really help to assess the exact size added by Restlet to a GWT application.

    We have just released version 2.0 RC3, including a size optimization for the GWT edition.

    We kept only the most often used MediaType constants, saving 6 Kb. This results in an absolute size of 159 Kb that can be GZipped down to 65 Kb, far from the nightmare you announce.

    Regarding the "spaghetti dish", could you elaborate a bit more?

    On our side, we are planning further optimizations. Our org.restlet.client.representation.ObjectRepresentation class depends on the GWT-RPC module for object serialization. We will move it to a separate extension, making GWT-RPC optional, further reducing the core size.

    In Restlet 2.1, we will also add an option to our client proxies generated via deferred binding to make them only rely on GWT's HTTP+RPC modules internally, saving the Restlet module size if no further inspection/modification of HTTP messages is needed at runtime.

    In the end, you should only increase your application size for the feature you really use/need. That's our goal.