Introducing GSS

During my recent work-induced blog hiatus, I've been working on a new software system, called GSS. I've been more than enjoying the ride so far and since we have released the code as open-source, I thought discussing some of the experience I've gained might be interesting to others as well.

GSS is a network, er grid, er I mean cloud service, for providing access to a file system on a remote storage space. It is the name of both a service (currently in beta) for the Greek research and academic community and the open source software used for it, that can also be used by others for deploying such services. It is similar in some ways to services like iDrive, DropBox and drop.io, but it can also be regarded as a more high-level Amazon S3. Its purpose is to let the desktop computer's file system meet the cloud. The familiar file system metaphors of files and folders are used to store information in a remote storage space, that can be accessed from a variety of user and system interfaces, from any place in the world that has an Internet connection. All usual file manager operations are supported and users can share their files with selected other users or groups, or even make them public. Currently there are four user interfaces available, a web-based application, a desktop client, a WebDAV interface and an iPhone web application, in various stages of development. Underlying these user interfaces is a common REST-like API that can be used to extend the service in new, unanticipated ways.


The main focus of this service was to provide the users of the Greek research and academic community with a free, large storage space that can be used to store, access, backup and share their work, from as many computer systems as they want. Since the available user base is close to half a million (although the expected users of the service are projected to the low ten thousands), we needed a scalable system, that would be able to accommodate high network traffic and a high storage capacity at the same time. A Java Enterprise Edition server coupled with a GWT-based web client and a stateless architecture were our solution. In future posts I will describe the system architecture with all the gory details. The exposed virtual file system features file versioning, trash bin support, access control lists, tagging, full text search and more.

All of these features are presented through an API for third party developers to create scripts, applications or even full blown services that will fulfill their own particular needs or serve other niches. This API has a REST-like design and though it will probably fail a formal RESTful definition, it sports many of the advantages of such architectures:

• system resources such as users, groups, files and folders are represented by URIs

• GET, HEAD, POST, PUT and DELETE methods on resources have the expected semantics

• HTTP caching is explicitly supported via Last-Modified, ETag & If-* headers

• resource formats for everything besides files are simple JSON representations

• only authenticated requests are allowed, except for public resources

Users are authenticated through the GRNET Shibboleth infrastructure. User passwords are never transmitted to the GSS service. Instead GSS-issued authentication tokens are used by both client and server to sign the API requests after the initial user login. SSL transport can provide even stronger privacy guarantees, but it is not required, nor enabled by default.

The GSS code base is GPL-licensed and therefore anyone can use it as a starting point to implement his own file storage service. We have yet to provide binary downloads, due to the various dependencies, but the build instructions should be enough to get someone started. We are always interested in source or documentation patches, of course (did I mention it's open source?). Most importantly, the REST API will ensure that clients developed for one such service can be reused for every other one.

I will have much more to say about the API in a future post. In the meantime you can peruse the code and documentation, or even try it out yourself. I'd be very interested in any comments you might have.

GWT and animation effects

I've already praised GWT and its highly productive environment for generating AJAX applications. I've been using it in my Very Cool Project with great pleasure, I must confess. Creating a highly interactive web application, brings back some of the entertaining aspects of programming again. Although, to be honest, it would have been nice to get rid of all those anonymous inner functions I find myself dealing with. Life (and code) would be a lot simpler with closures and higher order functions. Sometimes I find it ironic that GWT translates my anonymous-inner-classes-using code to JavaScript code with closures, higher order functions and all the other goodies. Apparently, a change of perspective is always an eye-opener.

My nagging aside, GWT is an enormous leap over other solutions for interactive web applications in Java. However, one area that has received little attention so far, is support for animation effects. The stuff that puts the candy in eye-candy. Certainly, there is always the option to use other JavaScript libraries that provide such effects through JSNI, like Scriptaculous, YUI, Ext JS and others. But that is not an efficient nor elegant way to do it. Memory leaks may creep up (particularly on Internet Explorer), separate download requests for the other scripts must be made and JSNI references are, er, how should I put it, um, chatty?

A better way involves using a GWT wrapper around the external effects JavaScript library. This way you get to reap the usual benefits of GWT, namely the minimum number of roundtrips to the server, compilation of just the code you need (the effects you actually use) and no detour to JavaScript-land (though lately I'm having second-thoughts about the goodness of this). The main solutions that have emerged so far are various Scriptaculous wrappers, an ext wrapper and gwt-fx.

I've tried both one Scriptaculous wrapper and the gwt-fx codebase and I would wholeheartedly recommend the latter. For starters, it feels like things are done "the GWT way": a single EffectPanel to decorate the widget that will be animated, separate effect classes for the most popular effects, sequential and parallel combinations of effects, deferred binding for browser-specific functionality, Listeners and Adapters and much more. Implementing a fade effect took me about 10 lines of Java code. And we all know Java is not the most succinct girl in town, right? Furthermore, while the Scriptaculous solution worked on IE, Firefox and Opera, it would barf on Safari (version 2 if you must know). gwt-fx worked on all of them without any special-casing in my code.

Also, when things don't work as expected, the author, Adam Tacy, is very cooperative and helpful. He has endured a flood of patches from me to solve some problems that I encountered, and when not satisfied with them, he implemented even better solutions after careful consideration and thoughtful reasoning. Just make sure to get the latest version (1.0.0) that has every bug I encountered so far, fixed.

Adding a supported effects library in the main GWT distribution has been discussed a few times on the contributors list, but apparently it is not a high priority task at the moment. For a good reason I might add, since the release of GWT 1.5 is just around the corner, with support for Java 5 and a whole slew of compiler optimizations. However, with the recent introduction of the GWT incubator project it might be appropriate to start trying out some design ideas on such a library and see how it goes. If you care for such an outcome, don't hesitate to let the GWT developers know about it, by joining the discussion in the recent thread on the subject.

The case of the disappeared Exception message in GWT RPC

Regular readers of this blog (both of you) will remember my recent love confession for GWT. While I am glad to say that my feelings have not changed one bit, like all maturing relationships, we are getting more intimately familiar with one another. To the point where you know things about your significant other that you'd rather never found out. And since I know there are many others with feelings for GWT, I thought I'd give you a tip or two, in case you want to make a pass.

In my previous post I didn't elaborate on the marvelous feature of GWT RPC. The RPC feature gives your GWT client the ability to communicate with your Java-based backend in a very powerful, yet painless, way. I still plan to discuss it more thoroughly in a future post, but for now I'd like to mention a particular bug (or feature) of the current implementation.

The RPC mechanism allows a client to make a Remote Procedure Call to the server supplying the necessary call parameters and getting back the results. Quite often (as it turns out) the server will encounter an exceptional condition during the execution of this call and will throw an exception to the caller. Luckily an Exception in Java contains a detailed message about the problem encountered (or more accurately its ancestor, Throwable) that the client can rely upon to present the situation to the user. To give an example, you could have an Exception class EarthShatteringException like the following:

public EarthShatteringException extends Exception implements Serializable {

private static final long serialVersionUID = 1L;

public EarthShatteringException() {
}

public EarthShatteringException(String message) {
super(message);
}

public EarthShatteringException(Throwable cause) {
super(cause);
}

public EarthShatteringException(String message, Throwable cause) {
super(message, cause);
}

}


This is pretty much elementary stuff, you extend the base Exception class and also implement the Serializable interface, in order to give GWT a chance to convert your exception object to tiny little bits, transmit them over the wire and recreate the object on the client. So the way you actually throw such an exception on your server might be something like the following:

public void doGreatStuff() throws EarthShatteringException {
if (something.isWrong())
throw new EarthShatteringException("God help us!");
else
doTheGreatStuff();
}

On the client you deal with the exception in a callback function you provide, called onFailure:

public void onFailure(Throwable caught) {
displayError(caught.getMessage());
}

In this example we just display the message contained in the exception to the user.

At least that's what you would expect. In fact, what this code will do in GWT 1.4.60 (the latest release as of this writing) is display the string null.

How could that be you say? I'm glad you asked.

Serialization in GWT is a little different than in the rest of Javaland. This is because the client in runtime is actually JavaScript code, compiled from our original Java code by the miraculous GWT compiler. The compiler uses its own private implementation of the standard Java class libraries, that implements a quite large, but still limited subset of it. In our particular case the implementation of the Throwable class does not implement the Serializable interface and the side effects that entails.

So when our exception gets transmitted over to the client, what gets instantiated is an EarthShatteringException type, but its supertypes are not serialized (hence transmitted) themselves. Therefore our stored error message gets lost somewhere in Cyberspace, never to be seen again. If your server-side code attempted to throw a standard exception subclass from the standard class library, like IllegalArgumentException, things could be even worse, like getting a ClassCastException.

The good news is that this is a known issue among the GWT developers. The bad news is that it is not fixed yet. However, a simple workaround exists. If you store a detailed error message in your own exception object and override the getMessage method (or its cousins) to return that copy, instead of the supertype's, it will produce the excpected outcome. For the previous example we could do it like this (changes in bold):


public EarthShatteringException extends Exception implements Serializable {

private static final long serialVersionUID = 1L;

private String message;

public EarthShatteringException() {
}

public EarthShatteringException(String message) {
super(message);
this.message = message;
}

public EarthShatteringException(Throwable cause) {
super(cause);
}

public EarthShatteringException(String message, Throwable cause) {
super(message, cause);
this.message = message;
}

public String getMessage() {
return message;
}
}


If you are a grumpy kind of person and hasten to whine about the apparent intricacies of GWT, rest assured that most of the time GWT RPC is painless as advertised. In fact it seems so easy that people are already hooking it to other server-side frameworks, like Seam and Spring. It provides an elegant way to hook a modern server architecture with the most innovative web client technology on the planet.

I promise you, you'll love it.

How I fell in love with GWT

The first Graphical User Interface I ever wrote was in BASIC. I was about 13 when I wrote it, so it was a GUI for a game. You only build important applications when you are young. As you grow older, you compromise on the 'important' part, but that's life I guess.

The GUI didn't do much and it was a very laborious experience by today's standards, but I remember enjoying every bit of it. I am a geek, you know. A few years later I was building a GUI in C. It was more sophisticated, but the effort had gone through the roof. I started using polygons and clipping algorithms and z-buffers and whatnot. I even had a few books to keep me company that still hold a prominent place in my bookshelf.

They got to lie on the floor for this photo, but we've come a long way together and they didn't mind.

Anyway.

Using geometry and trigonometry to create a GUI, made the stuff that I was learning at the time in school actually interesting. Or perhaps it was the other way around. Who knows. It got frustrating after a while though, so when I discovered Windows and the Microsoft Foundation Classes, it felt like a godsend. I even got new books to celebrate the occasion.

But programming for the PC can only get you so far. Now that you can program for your phone, how could you let the opportunity pass? I couldn't. I started reading up everything I could find about Java Midlets and the Symbian OS. No books this time, everything was online. The development experience was great. You could do very little stuff in such a small machine and the process seemed like constantly solving puzzles. The GUI was the easiest part. You got a menu, two soft-buttons and some form fields. That's your interface. You could use any color you wanted, as long as it was black. I had great fun doing it, but my company was making more money in enterprise software, so eventually I found myself working in the Enterprise Java Software world. A place even the brave ones fear to go. Probably because it involves putting an HTML GUI on top of a Java server application, which is as scary as it sounds. If you are not a hopeless geek, that is.

The worst problem with such an arrangement is that you constantly have to context-switch your mind from one language to another: from HTML to Java, then to JavaScript, then back to Java, and so on and so forth. It's the same burden as using straight SQL to access your database (but let's not get into that again). And the tools aren't very helpful, either. The gap between these technologies makes you debug the same use case separately. Nowadays you have to add AJAX capabilities in your web-based apps, which only makes things worse. When I first used AJAX in the development of an HRM system a few years ago, it felt hard. When trying to find out why a certain widget was not getting updated, we had to use a Java debugger to see whether the server was sending anything and then a JavaScript debugger to check whether it was coming to the browser at all. It was madness, I'm telling you.

[By the way, if you have no idea what an HRM is, ask your hiring manager, he uses one. If he doesn't, tell him to give us a call. We can help.]

So when I heard about GWT, I instantly got excited. It promises to free us from the torture of creating the GUI in HTML/JavaScript and the backend in Java and it delivers on its promise. You do everything in Java! You create the interface pretty much the same way you did it with MFC back in the day and it gets transformed into JavaScript code of the highest quality to execute on your browser. All of that in the comfort of your Eclipse IDE. Apparently we have the same taste in IDEs with Google.

I've been reading about it for a year now, but I wanted to get some first-hand experience, before bragging about it. The opportunity came with my new Very Cool Project, which I can't talk about yet, so I'll just call it VCP. It's like VIP, only cooler. The Coolness of the project exists independently from GWT, but this is the icing on the cake. What would have been a technical wonder with a boring GUI, will now become a highly interactive experience that will validate the underlying technology. Just like what happened with GMail. Nobody cared much about Google's low-level technical marvels, until it hit them in the face through the excellent interactivity of the GMail GUI. Hopefully that's what is going to happen with VCP as well, if everything goes as planned. Yeah, I know. Like it ever does.

But with GWT, I feel quite confident. Creating a GUI is so easy that I made the VCP mock-ups in it. We used to do it in plain HTML with web designer tools and when we started developing we would copy the HTML files to JSP ones and change stuff all over the place. It took me only slightly longer to finish the task with GWT, but I already have working code to use. I can use the time I would spend coming up with a first-pass working prototype, to make a trip to Tahiti.

Just kidding. Like they would ever let me do it.

The other thing I like a lot about GWT is that it's open-source. And with the best license, Apache 2.0. This has already been quite handy in VCP, when I stumbled upon a bug during my upgrade from version 1.3 to 1.4RC. A simple request for help in the forum and a bit of source code reading, and I came up with a workaround in no time. And identifying the bug was the easiest part of all. I got a stack trace of my Java code and using Eclipse I could immediately pinpoint the culprit.

There is much more in GWT than that, though. You get easy browser 'back' functionality. No more 'history stack' for us, thank you very much. You can unit test your interface with JUnit. Do that with a HTML/JavaScript GUI if you dare. And perhaps most important of all: cross-browser compatibility. The Googlers have gone into the trouble of coming up with implementations for numerous browser inconsistencies and they have hid them inside the GWT classes. You only program against one GWT API, not against half a dozen JavaScript & DOM implementations.

I still haven't got a proper book about it, though. You know, for company and all. I did however, make the first step: I put it in my wishlist.