Google Web Toolkit

I have been playing with Google Web Toolkit. And these are my thoughts about this framework:

Pros

• You don’t have to worry about JavaScript. You develop the user interface in Java. Then GWT compiles the code to JavaScript. Yes, with a little bit of magic and some limitations.
• Cross-browser support.
• Easy to use.
• Good IDE integration. Since you develop in Java you can use lots of developing tools such as Unit testing, debugging, auto completion,…
• When deploying your application in hosted mode you have a shell and browser window in which you can debug errors. Errors in hosted mode are Java errors: you have a stack trace, so you can easily find what is wrong.
• If you make a user interface change you don’t have to restart the shell. You just need to refresh the browser window.
• Easy Remote Procedure Calls. You can call server code from the client code like any other method call. GWT serializes and deserializes the arguments and the returned value.

Cons

• The unique thing I don’t like is that opening a shell is too slow. If you make changes in the server code you have to open a new shell and the new shell needs to start an embedded Tomcat server. You spend several seconds opening a new shell.

Google App Engine

Last week Google released Google App Engine. With this new service you can develop web applications and deploy them in the Google infrastructure. The benefits are: scalability (automatic load balancing, replication), fault tolerance, high availability, easy deploy, easy administration and… it’s free to get started!

Every Google App Engine application can use up to 500MB of persistent storage and enough bandwidth and CPU for 5 million monthly page views.

By the moment this service is a preview release. But is easy to figure out that this service will be fundamental for several future startups.

The runtime

The SDK is less than 10Mb in weight once installed and is very simple to use. You start the server and everything is reloaded when you make changes. So you don’t have to restart the server in any case. With one command you can deploy the application to the Google servers and with other command you can switch to a previous version if you, for example, inserted a critical error in the latest version.

By the moment you can only develop in Python 2.5. They are planning to support more languages. The community wants Java, Ruby or PHP to be supported. But in my honest opinion I think Java would be difficult to be supported.

If in a future Google adds support for the Java programming language I think it won’t be JavaEE standard. As with Android that isn’t JavaME standard and even it does not compile to standard Java bytecodes. I think it will be something much more easier to deploy than JavaEE. And you won’t develop servlets but something similar. But this is just my opinion.

The datastore API

The persistence API of Google App Engine has the following features.

• Scalable. You don’t have to worry about replication, fragmentation,… Even you don’t have to worry about indexes. When you are developing the SDK determines the indexes based on which fields are most used in queries.
• Easy to use. The data modeling API is very simple. You don’t have to create tables or synchronize them with your domain model. You just create a class that extends from db.Model (or db.Expando) and then automatically your class is persistent. It has methods for inserting, updating and deleting (put() and delete()). To query the database you use a simple query language called GQL similar to SQL. However you have the following restrictions (or features ).
  • Your classes have one and only one primary key. This key is auto-generated.
  • There are no JOINs. In a distributed and scalable environment is pretty difficult to implement an efficient mechanism to support JOINs Google has said.
  • You have a set of available data types.
• No tools for getting data on and off Google App Engine. But Google is working on it.

Other APIs

The runtime comes with other interesting APIs

• Users API. An authentication API based on the Google accounts. Isn’t it more or less similar to  Microsoft Passport? I would love Google supporting OpenID. Google joined recently the Dataportability Working Group (that defines the OpenID standard and others). Also several developers want support for OpenID in Google App Engine. So, in my opinion, OpenID support is a MUST.
• URL fetch API and Mail API. Some Python standard APIs such as threads, sockets and some functionality related to the file system are disabled for security and scalability reasons. So Google provides these specific APIs to let your applications consume web services or send mails.

What about Amazon

Amazon has well known web services that compete directly with Google App Engine: SimpleDB and EC2. But I think Google App Engine is better for some reasons:

• Free to get started.
• SimpleDB has huge limitations. However Amazon is planning new features.
• Google App Engine is absolutely easy to use. You don’t have to care about how many servers you need. How much band width. You don’t have to care about elastic IPs or things like that. And deploying is soooo easy in Google App Engine.

Nevertheless with Amazon you get much more flexibility. You don’t have the restrictions of the Google App Engine runtime (language, APIs,…) and your application won’t be Google-specific.

By the moment Google doesn’t compite with Amazon in file storage. Google App Engine free accounts provide you with only 500Mb. However you don’t need more: you can’t write in the file system. Maybe 500Mb are sufficient if you need to store images uploaded by the users (for example). In that case you can insert them into the datastore as Blob objects. In other case you can purchase more disk capacity or you can use Amazon S3.

Conclusions

Google wants developers to build great web applications that interoperate with their systems.

• You develop with Google-specific APIs.
• You have an API that authenticates users with Google accounts.
• All your data in the datastore can be converted to GData (just .to_xml() in your domain classes).

A great service with great features. But, too much Google-centric? Yes, but it is by far the best service I’ve seen since Amazon S3.

Technologies for building Rich Internet Applications

Nowadays RIA, Rich Internet Application, is a well-known acronym. But what is it? It refers to web applications with a rich user experience (like desktop applications).

At the begining of the WWW everything was plain HTML (HyperText Markup Language). So we had a document based technology. With plain HTML you have text, images, tables, forms and the most important: hyperlinks. When you click an hyperlink you are directed to another web page. All the content is replaced in your web browser window with the new HTML document: the previous one disappears. HTML forms are quite simple. What do you do if you want the user to input a date in a form? The only solution is to let the user submit the form and then if there are any input errors redirect the user again to the form showing those errors. And if you want the user to upload a huge file? Yes, there is an input component to submit files, but what happens when the file is big? The browser doesn’t tell the user how long it will take to upload it or which percentage has already been sent. It just says “sending request” and that’s everything but usable. And what happens if you want the user to select a “country” and a “state/province” in a form? In a desktop application you’ll put a combo box for selecting the country and another one to select the “state/province”. When the user selects a country the state/province combo is filled with the states or provinces of the selected country queried from a database for example. How can you do this with plain HTML? Sorry, you can’t. On balance HTML lacks of rich user experience.

Well, to solve these lacks JavaScript came into the scene. With JavaScript and the DOM API you can change everything on a web page. That’s cool and useful. You can do client-side form validation, you can let the user to pick a date in a calendar,… But what happens when you want to fetch data from the server like in the country-state example? The first trick was to use invisible frames or internal frames. With this hack you can load data in a separate frame and read it from another frame with JavaScript. That was the beginning of AJAX. Now we have XMLHttpRequest which is a more elegant way to perform this tasks.

So JavaScript provides functionality to build Rich Internet Applications! But… you know what? Some people doesn’t like JavaScript because it has several incompatibilities between browsers, it doesn’t support good OOP and usually breaks the accessibility and visibility (to search engines) of your web applications.

Well, if you don’t like JavaScript you have some non-JavaScript technologies to build Rich Internet Applications:

• Java applets. They are an old-fashioned solution but during some years was common to build applets for intranet applications. You can communicate with the server and fetch data using sockets. Probably you need to sign the applet for security reasons but that’s not a problem for intranet applications. And you need the users to have Java installed but again this is not a problem for intranet applications but maybe yes for internet applications.
• Adobe Flex. The approach is the same of the Java applets: through a plugin you put little applications in any HTML document. In this case you use the MXML and/or ActionScript languages to build the user interface and to code the logic. Then the code is compiled to a Flash movie (.swf) that can be executed by the Flash Player. Its benefits are:
  • Flash is installed in almost any personal computer connected to the Internet (everybody watch videos on YouTube).
  • No compatibility issues because there is just one Flash Player complete implementation.
  • Easy development, good user experience, eye-candy graphical interface.
• OpenLaszlo based on the same approach of Flex with two major differences
  • It is OpenSource. Ok, Flex will be, but not the Flash player by the moment.
  • You can compile your code not only to Flash but also to HTML+JavaScript.
• Microsoft Silverlight is a new technology that competes with Adobe Flash and Flex.

And what if you like JavaScript but you don’t want to reinvent the wheel or you can use it as less as possible? You can use a server-side or client-side JavaScript based solution.

Some client side solutions (JavaScript libraries):

• Ext JS has a fantastic ready-to-use set of widgets such as grids, trees, dialogs,… I already talked about it in a previous post.
• Dojo is similar to Ext JS but in my opinion it’s more limited. However it has useful components to create mush-ups. For example you can easily integrate Google Maps into your application.
• Prototype is a popular JavaScript library that eases the use AJAX into your applications.
• Others: script.aculo.us that is built on top of prototype and provides an animation framework, drag and drop, AJAX controls, DOM utilities, and unit testing facilities; mootools also providing AJAX facilities and JavaScript effects.

Some server side solutions (server side frameworks):

• GWT (Google WebToolkit) is a Java web framework. With this framework you create graphical interfaces very similar as you will do with Swing and then, with some kind of magic, the Java code is compiled to JavaScript code. At development time you can test your application inside a Java Virtual Machine in a simulated environment with the benefit that you can use any of the development tools available for the Java programming language. It makes JavaScript transparent to the developer.
• JSF (Java Server Faces) is a Java technology derived from JSP (Java Server Pages). You write JSP files with the taglib set provided by JSF. These taglibs render rich widgets. Then you can write code in Java that responds to the events of those widgets (like a desktop application). Like GWT it also makes JavaScript transparent to the developer. JSF is designed to provide rapid application development. There are several graphical tools for creating JSF based web applications.
• Ruby-on-Rails (RoR) is a pioneer framework on providing AJAX facilities.
• Other frameworks: nowadays all the most popular frameworks available for any language provide functionalities for building Rich Internet Applications. Some examples: Symfony for PHP or TurboGears for Python.

Ok, is there any additional rich user experience we want in our applications? Let’s see. All these previous technologies are web based (you need a browser) and you cannot work off-line with them. If you are not connected to the Internet you cannot use them. To achieve this issue recently Google has released a new technology: Google Gears. With Google Gears you can access a local relational database with JavaScript so you can store large amounts of data in the client side. So you can replicate data on the client side letting the users to query those data when they are off-line. GMail supports Google Gears so if you have it installed you can read your mail off-line. Other Google services like Google Calendar also support this technology.

Anything more? Let’s go further. Now you want deeper desktop integration. You want the user to be aware to open your application with double click using a custom icon and you want your application to be ran in a separate window (not in the browser), without the typical tool bars in a web browser: address bar, bookmarks,… Has somebody thought about that before?

• Prism is a project from the Mozilla Fundation. You can launch your web-based applications like a desktop application: with a separate window without any toolbar, with a double-clickable icon, and basically that’s all by the moment.
• Adobe AIR (called Apollo in the alpha version) is a runtime environment that let’s you use several technologies such as Flex, Flash, HTML, AJAX and PDF. It has a built-in web rendering engine (WebKit) to support all those technologies and brings you some other features:
  • You can make an installer for your application.
  • Double-clickable desktop icon to launch your application in its own window.
  • You can create local relational databases because it comes with SQLite.
  • Drag-and-drop support with the underlaying operating system.

Fantastic. You have a huge set of technologies. Is there any more? Well, yes. There is another way of making Rich Internet Applications: you can avoid any web-centric programming language and create a desktop application written in any language that consumes data from web services. For example: Google Earth, Flickr Uploader or Twitterrific. With this approach you don’t have any limitation in the user experience. But you loose one big feature of web applications: installation and upgrades are transparent in web-based applications. With Adobe AIR you have the same problem. Is there a solution? From several years ago if you develop a desktop application using Java SE you can distribute it with Java Web Start. Using JWS (Java Web Start) you create an XML file in JNLP format and with .jnlp extension. In that file you define where the application is hosted, which version of the Java Runtime Environment is needed and much more. Then you put an hyperlink into your web linking to that JNLP file. If the user has that file type is associated to JWS (you can detect with JavaScript if the user has JWS installed) when the user clicks on the hyperlink Java Web Start downloads, installs and launches your application. Everytime the user runs the application Java Web Start asks the server for upgrades and downloads them if available. Of course this technology is only avaiable for Java applications. However if you don’t use Java or don’t want to use JWS you can always create your own upgrade system by hand.

Finally you can also create an hybrid as explained in a later post: Making double clickable Java EE web applications.

Anything more? Yes! I haven’t talked about mobile solutions! Maybe in a future post… By now remember this: Rich Internet Applications are here and all these technologies I have talked about are changing the way of how Internet applications are being developed.

Ext JS - Java Script library for Rich Internet Applications

I have just discovered this amazing Java Script library: Ext JS. The interactive demos are awesome. This library has an extremly good set of components such as trees, grids, dialogs, menus, forms, etc. These components have lots of functionallity and thay are beautiful. Also you can change their appearence with four default themes.

This library is OpenSource. It is free for commercial and non-commercial use or you can purchase a commercial license.

If you are a Java programmer and you use GWT (Google Web Toolkit) or you are planning to use it, you should know that there is a new project that integrates ExtJS with GWT: GWT-ext.

Making double clickable Java EE web applications

A few days ago I was playing with JAX-RS and Jersey when I thought “oh, what easy it is to run this kind of web applications” because of you don’t need a servlet container. Wait! I can run this applications using a plain main() method so… these kinds of application are desktop applications? I can make a main() method that launches the Http server and opens the web application in the default web browser. Mmmm and I can put a tray-icon to re-open web browser if the user closes it or to stop the web server. On balance your main() method does these things:

• Launches the Http server that comes with Java SE 6
• Opens the default web browser to any URL inside your application (http://localhost:8081/something)
• Places a tray-icon that can be used to open the main URL (http://localhost:8081/something) or to stop the Http server.

How? With Java SE 6 is easy with its new Desktop and System Tray APIs. You can see sample source code of all these ideas.

When you are done you can distribute your application in a JAR executable file or you can wrap it into an exe file. Do you need a database? You can use Java DB included in Java SE 6 or other embedded database.

So… what are we doing? We are distributing a web application as a desktop application. What is this useful for?

• Prototyping and demostrating: you can send your application to someone without more requirement that a standard Java SE 6 runtime installation.
• Web applications working on-line and off-line. You can create two versions of your application sharing most of the code. One version will be a “desktop application” and the other one will run in a servlet container. If the user is off-line he can use the desktop version, and when he goes on-line the application can populate the changes to the server. So the desktop version can act as a data cache. The user can also work on-line in any workstation with the on-line version wich has the same user interface that the other one.
• You want to create a desktop application and you love web design and development.
• You want to create a mash-up desktop application using services such as Google Maps that are more easy to use with an HTML + CSS + JavaScript interface.

Introducing JAX-RS (JSR 311) and Jersey

JAX-RS is a new JSR (there is no final release yet). Jersey is its reference implementation. JAX-RS will be part of Java EE 6 and is intended to be used to create REST web services. It has an non-obtrusive and simple to understand API. Here you can find a brief example.

As you can see in the example you use annotations to map resources and methods to URIs (i.e. @UriTemplate(”/users”) ) and to indicate the content type of the response (i.e. @ProduceMime(”application/json”) ). Your methods can have any name and you don’t have to extend a certain class nor to implement any interface. So making unit testing is extreamly easy.

The HelloWorld example doesn’t demonstrate one of the great things about JAX-RS: the EntityProviders. They are responsible or reading and writing requests and responses as objects. Jersey comes with severeal useful Entity Providers and you can create your own ones. The Entity Providers that come with Jersey let you read and write:

• JSON objects with Jettison and optinally annotated with JAXB. More information.
• XML with JAXB.
• ATOM and RSS feeds with ROME.
• Strings, byte arrays and streams.
• URL encoded request bodies (i.e. a request generated submitting a POST form from a browser).

You can also bind request parameters to method arguments. Example:

@HttpMethod("GET")
@UriTemplate("{userId}.txt")
@ProduceMime("text/plain")
public String sayHello(@UriParam("userId") String userId) {
    return "Hello " + userId;
}

Note how easy is to test this method.

Other thing I like a lot is that you don’t need a servlet container. This API is intented to be used for applications deployed in a J2EE container but you can make a main() method and use a lightweight Http server that comes with Java SE 6 (if you are using Java SE 5 there is an http.jar file in the jersey distribution with this lightweight Http server). So if you develop applications using this API the unit testing is extremely easy and you can also test them quickly without having a J2EE server running.

I have some cool ideas based on this API. I’ll tell you in future entries. By the moment you can see some example code.