RAP, what? The Eclipse community is expanding its range to Hip Hop
? Not exactly, although there is a chance. Eclipse Rich Ajax Platform(RAP) is a framework that empowers developers to build rich web clients “the Eclipse way.” From the latest Helios download, RAP Tooling has become a default component of the RCP bundle:
![]()
So what exactly is the Eclipse paradigm? Can we benefit from it?
RAP is to the web as RCP to the desktop. It inherits all the goodness from RCP such as workbench extension points model, event-driven SWT/JFace APIs, and componentized OSGi design. As indicated below [4], the only difference between the architecture of RAP and that of RCP is the implementation of SWT/RWT. RWT is actually a bundle providing web-specific implementation of SWT’s widgets based on the qooxdoo toolkit. In RAP, almost no SWT API is changed.
This architecture determines that developers can bring their RCP applications to the web with a single code base, also called single sourcing [1]. Like building a RCP application, building a RAP application is a process of building plug-ins and bundles: On the UI side, contributing widget plug-ins; On the server side, since it is powered by server-side Equinox, contributing servlet plug-ins. Unsurprisingly, it also inherits the benefits of any OSGi application such as dynamically adding/removing bundles.
This architecture also determines that RAP is a server-centric AJAX framework. As indicated below [3], in a server-centric framework, the application is hosted on the application server and all processing is done on the server. The client browser is only used for data presentation. Consequently, it leaves small footprints on browsers: it waits for instructions from the server to create corresponding widgets on demand. In contrast, client-centric framework such as GWT statically compiles all widgets beforehand.
Both methods have pros and cons. Server-centric frameworks handle all communication automatically and leaves as few as JavaScript codes on the browsers as possible, hence potentially having less security holes on the browsers. Client-centric frameworks are more flexible but require more work to step deep into low-level implementations of client-to-server communication, e.g., figuring out how to update widgets effectively in an asynchronous callback.
For a Java-based rich AJAX application, while server side can be tested with JUnit, testing UI is always a headache. Like GWT, testing UI has to rely on external JavaScript libraries such as JsUnit. But for RAP, since it’s server-centric, UI code can be tested using JUnit with the special RAPTestCase. Moreover, since the workbench APIs haven’t been changed, all existing SWT testing tools can be reused, e.g., Selenium or SWTBot.
In general, RAP pushes more work off the client onto the server, thus communicating more information and more frequently with the server. Some performance testings were available.
RAP is extremely easy to deploy on an OSGi based server [2], e.g., Spring dm server which has moved to the Eclipse Virgo project, because its server side implementation bases on the http OSGi standard. Deploying to a traditional J2EE such as Tomcat requires packaging an extra “Servlet Bridge” into the war. A drawback of RAP is that it can’t be deployed to a plain web server such as Apache. You can do this to a GWT-based application without RPC and the generated JavaScript codes will still work fine on a browser.
RAP is created to provide developers a possibility to bring the goodness of RCP applications to the web without the need to digging through low-level web-technologies. This greatly reduces cost by reuse of knowledge and code. It provides a thin client with a rich widget set and a stageful server-side on top of OSGi, and reuses the Eclipse workbench paradigm. As OSGi-based web containers such as Spring dm server are getting more prevalent, RAP will definitely enjoy more popularity.
[1] Eclipse Rich Ajax Platform: Bringing Rich Client to the Web
[2] EclipseCon 09: RAP or GWT – Which Java-Based AJAX Technology is for You?
[3] ZK vs. GWT : Server-Centric Matters!
[4] Eclipse Rich Ajax Platform (RAP)
Nice article. But I have to correct something: RWT is not a patch fragment. It’s a bundle that just provide the SWT api.
I like this blog. It’s a nice and easy introduction to RAP.
Thoug one thing struck me. The statement
“[ ... ] it can’t be deployed to a plain web server like any GWT-based application which can be bundled with a Tomcat” unde r”Deployment” is not quite right.
RWT, the SWT-implementation for RAP, has no dependency on OSGi. Together with the application code it can be packaged into a WAR and deployed on any servlet container just like GWT. See this FAQ entry for further details:
http://wiki.eclipse.org/RAP/FAQ#How_do_I_use_a_RWT_standalone_application_in_Tomcat
To Holger: Thanks for the clarification! I thought RWT is a patch fragment but turns out it’s just duplicating all the SWT APIs. I have changed the article to prevent confusion
. But I think making it a patch fragment will make more sense? Prob. the RAP guys have other concerns…
To Ruedlger: Sorry about the confusion. What I really meant is RAP apps can’t be deployed to a *plain* web server. GWT is translating Java to JavaScript. If the app doesn’t have any RPC, it can be deployed to Apache and still works fine.
Nice post!
Burn Notice New Season
it was very interesting to read owenou.com
I want to quote your post in my blog. It can?
And you et an account on Twitter?
You made some good points there. I did a search on the topic and hardly found any specific details on other sites, but then great to be here, seriously, thanks…
- John