RAP becomes the Remote Application Platform

RAP becomes the Remote Application Platform

RAP is approaching its second major release in its 6 year history, and major releases should be accompanied by major new functionality – at least this is our take on versioning.

With RAP 2.0 we are changing the project name from Rich Ajax Platform to Remote Application Platform (RAP as a short name remains the same), so there is something really significant happening. RAP has always been an implementation of the half-object pattern – synchronising the User Interface between a server and its clients. A specialty of RAP is that the half objects are implemented in different languages. The server part uses Java, the browser client is using JavaScript (and HTML5) for implementing the half objects. Recently we added (commercial) clients for Android and iOS providing native widgets to mobile users. The implementations of the clients are using the corresponding languages – Java and Objective-C. With version 2.0 RAP is no longer only an AJAX framework for creating powerful web applications, it is becoming a platform for remote applications independent of the UI technology that renders the client.

Implementing clients in other languages has become possible with the introduction of the RAP protocol, which standardizes the synchronization of objects between the RAP server and its client based on JSON based messages.

The protocol does not only enable clients in other programming languages, it also opens the door to a new class of applications – applications that need to address a wide range of hardware from desktops to specialized devices (e.g. mobile data entry or point of sales solutions). Or applications that require an integration with attached hardware devices. We think that this is a major new achievement for RAP warranting a major release – and a feature that sets RAP apart from other frameworks.

My colleague Ian Bull created a proof-of-concept implementation of a native SWT client. This is interesting because SWT already implements support for 14 platforms. The creation of the proof-of-concept took only a single day using our Android implementation as a template.

If you want to get your feet wet and implement a client for another platform the only thing you need is the latest milestone build from RAP. If you need help, existing code or a partner for the implementation, just contact us.

  • Tom Schindl
    Posted at 9:57 pm, November 26, 2012

    So can i sync any object graph between server and client or is it optimized to SWT controls and the client has to have an SWT-like-API implementation?

    More concrete can one do something like Canoo does with https://github.com/canoo/open-dolphin e.g. writing an JavaFX-Client?

  • Ian Bull
    Posted at 11:20 pm, November 26, 2012

    You could easily write a client in JavaFX (I was debating that last week when I wrote the SWT one). You just need to implement the client side of the RAP Protocol (which is simply JSON). You could implement the client in C# with a MetroUI, or even a C client that uses NCurses.

  • Tom Schindl
    Posted at 8:17 am, November 27, 2012

    Ian, do I not need both a stub version on the server e.g. SButton where e.g. my action handler is attached to and on the client a CButton which calls out to the FX-APIs?

    I’d really like to take a look at this in conjunction with JavaFX. Hope I have time to play with it soon.

  • LuisCM
    Posted at 11:58 am, November 27, 2012

    Great post!

  • Jeeeyul
    Posted at 5:19 am, November 28, 2012

    It’s so cool!

  • Rajesh Gupta
    Posted at 2:43 pm, June 30, 2017


    I have an RCP application which is embedded as RAP application.

    It works really well.

    However do we have a solution to automate such applications via Tools like TOSCA, UFT & Selenium