RAP protocol: On the way to RAP 2.0

If you are using RAP [Remote Application Platform], we maybe share the same opinion about it. I think RAP is a damn cool technology. You can write your plain RCP code and just run it in a browser by switching your target and add some extensions. On the first look this is just like magic. But if you take a closer look at the underlying RAP technologies it’s not so much magic anymore. The truth is that RAP has to fight a war against the underlying browser technology. The technology I talk about is Javascript. RAP uses Javascript heavily for rendering widgets. This rendering is currently done by qooxdoo, a Javascript UI-Framework. The bad thing about this is the following: The Java code of a RAP application runs on a server. To use your UI in a browser the server has to send messages to the client for rendering the UI. The other way around the client also has to send messages to the server to keep both sides in sync.

And how is this done at the moment? As I already mentioned RAP uses a Javascript framework called qooxdoo for rendering the widgets into the browser. As a result of this the server sends qooxdoo specific Javascript code to the client. The client instead uses HTTP POST messages with request parameters for sending messages to the server. This keeps both sides in a synchronous state. The downside is that the RAP server is tightly coupled to the current client technology. This means that RAP is always limited to use one rendering kit on the client. As a result of this RAP depends on the strengths and the weaknesses of this particular Javascript framework. To make this situation better a concept called the “protocol” comes into the game.

With a protocol we mean a well defined way how the server and client communicate. The protocol should replace the Javascript messages and the HTTP POST request parameters with a well defined message. If RAP has such a protocol, the underlying client would be loosely coupled to the server. As a result of this the client side will be replaceable. And this is one of the biggest benefits of the protocol.

Imagine the following scenario: You have successfully developed an SWT/RCP based application for the desktop. With RAP you have the possibility to run your application in a browser too. But with the protocol a bunch of different RAP clients are possible. Let’s say a RAP client for the iPhone exists. With this you can simply switch your target and create your IPhone application based on your RCP code without changing it. Another scenario could be to create a RAP Java client with SWT. With this you have no longer to single source your application for RCP and RAP. You just have to create your RAP application and switch your target to the RAP SWT Client. A lot of different client technologies are possible and with it many platforms too. So, to put it all in a nutshell you will be able to use your RCP code on one server and access it with n clients using n different client technologies. The image bellow shows such a scenario in a visual way.

Well, this is just a daring outlook what will be possible with the RAP protocol. It’s still fiction but the thing is, we currently work on it as part of a research project. The first tests are very promising and we are on the way to different RAP clients. I will keep you up to date on the progress of the protocol and I would be glad if you can post your ideas and feedback for this intend.