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.

protocol1 RAP protocol: On the way to RAP 2.0

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.

You may also like...

Share this Post

Twitter0
Google+0
LinkedIn
Facebook

Tags

8 Responses to “RAP protocol: On the way to RAP 2.0”

  1. Cole says:

    This is very interesting indeed. While I don’t think that running the exact same application on a desktop and an iPhone makes much sense (at least for something as complex as we have), the possibility to use our existing skills would be very beneficial. Of course there is still the hurdle of writing the client in such a way that apple will approve it for the app store, but that’s another story entirely.

    Drop me a line if/when you need beta testers for this!

  2. Austin Riddle says:

    I think that the idea of a proprietary RAP Protocol is what will keep RAP at the top of its game in future years. However, I would be cautious about thinking that single sourcing will disappear. What is supported and not supported on various client platforms will eventually trickle down to the application developers, who will have to make decisions on how to support/implement certain domain features that rely upon missing client side features from certain platforms. In any case, I think that fighting the browser wars and the client side platform wars (they are very similar) is definitely a way to expand RAP’s viability in different venues.

  3. Scott Lewis says:

    Hi Holger,

    Not sure if I need to point this out to you, but many of the problems you describe would go away if RAP used ECF’s transport/protocol-independent APIs for interprocess communication. That’s largely what ECF is about…creating communication APIs that are independent of wire protocol.

    Scott

  4. @Cole: You are absolutely right. The real challenge in this scenario is to convert one UI concept to another, e.g. Desktop to IPhone. But you already figured out the second benefit. Reuse of knowledge. ;) The apple licensing is really an own story for itself and I think after the last change of the apple license agreements there will be no way to develop Java apps which will run on the IPhone (same story with the Adobe Flash-IPhone compiler).

    @Austin: I guess you are right. Maybe single sourcing won’t go away. This was just an visionary scenario how the world can look like if anything works as we want. But it’s nice to see that you like the idea of a protocol ;)

    @Scott: Thanks for the hint. I think one problem of using ECF in this context is that the API’s you described are completely in Java. So, we always have to handle with client technologies like JavaScript, Objective-C and so on. I think a very lightweight protocol would be the best. The thing is, we need to couple the RAP server to some kind of message. The server has to understand this messages and synchronize the server side widgets. The other way around we need to make every client able to generate those messages and I don’t know if ECF is the right way in this case. What do you think about the described situation?

  5. Csaba Koncz says:

    Very much interested in this. Have exactly the problem described above: already existing RCP and RAP interfaces and now need to support a Swing client for the same app. The first idea was to use RAP to serve also the Swing client but faced the deep RAP-Qooxdoo symbiosis.

    Would be really interested in how you attack the problem.
    (What we tried is to build a model of the UI to be presented (using EMF) and then synchronizing client and server model instances with EMF Compare/Match/Diff/Epatch/Merge. The UI model is UI toolkit agnostic, so it can be rendered using whatever library the client prefers. This now works for not too complicated cases, but is far from being ideal or complete.)

  6. Hi Csaba,
    the thing is we don’t have plans to create a Swing client. When the protocol will be ready you can build one on your own very easily. All you need to do is write a processor for protocol messages an interpret the messages for your specific client technology. So, I will blog about this more when we have more concrete information. I would be glad if you and your team would build a Swing client. Maybe this can be contributed back to RAP in the future. ;)

  7. Scott Lewis says:

    @Scott: Thanks for the hint. I think one problem of using ECF in this context is that the API’s you described are completely in Java. So, we always have to handle with client technologies like JavaScript, Objective-C and so on. I think a very lightweight protocol would be the best.

    @Holger: I think the ‘java-only’ issue is a red herring…i.e. it’s not an issue. With protocols, they can typically be implemented in any language (witness xmpp), and further…as you probably know one can use native code libraries in OSGi (and therefore ECF).

    WRT this: The thing is, we need to couple the RAP server to some kind of message. The server has to understand this messages and synchronize the server side widgets. The other way around we need to make every client able to generate those messages and I don’t know if ECF is the right way in this case. What do you think about the described situation?

    Yes, ECF is a right way. With ECF’s transport-independence you can define whatever message format you wish…based upon some other lower-level protocol, or of your own format down to the wire.

8 responses so far

Written by . Published in Categories: Planet Eclipse

Published:
Apr 28th, 2010
Follow:

Twitter Google+ GitHub Facebook