RAP 2.0 Countdown (1/5)

After more than six years of RAP 1.x, we will release version 2.0 on February 11. As the version number suggests, there are some substantial changes in this release. During the last few days before the release, I will guide you through the most important changes in RAP 2.0. It’s not so much about new features, but also about some realignments we made and the ideas behind them.

[ More on RAP from our blog: RAP technology overview | Using RAP in an industrial setting? Our technology subscription secures your investment for years to come. ]

Remote – The New “R” in RAP

At the very core of RAP, there is an implementation of the “Half Object plus Protocol” (HOPP) pattern. The widgets in RAP are cut in half, one half is located on the server, the other on the client. Both halves are connected by a protocol. One big advantage of this design is that the application doesn’t have to take care of the client/server communication at all, the platform covers this.

RAP always had half objects but the protocol part was missing. The communication was based on undocumented JavaScript commands and HTTP parameters. Starting with RAP 1.5, we migrated the entire platform to a new, open JSON protocol. This protocol opens the platform for alternative clients, and those clients already exist. With Tabris we provide native clients for mobile devices with iOS and Android. For me the best proof that the protocol works is that although the Tabris team works next door, there’s very little need for technical discussions. In fact, the protocol is the interface between us.

Writing a RAP client isn’t rocket science, all you need is an HTTP client, a JSON parser, and part of a graphics library for displaying widgets. You don’t have to implement the full widget set, only those widgets that your applications require. We’ve already seen some PoC clients and we can’t wait to see RAP on more devices.

The RAP protocol has been under development for quite a while and has been simplified a couple of times. Let’s have a quick look at the structure of client and server exchange JSON messages. A message consists of a header part and a list of operations:

{
 head: { … },
 operations: [ … ]
}

The operations are executed by the receiver one by one. There are six types of operations: create - to create a remote object, set - to set one or more properties on the remote object, and destroy - to well, you guessed it. Besides set there is also call to call a method on a remote object. In addition, finally listen and notify to exchange events. Every remote object is identified by an id and every operation addresses exactly one target object. That is basically it. To give an example, here’s a message that creates a Button with a Selection listener:

{
  "head": {
    "requestCounter": 1
  },
  "operations": [
    [ "create", "w4", "rwt.widgets.Button", {
        "parent": "w2",
        "style": [ "PUSH" ],
        "bounds": [ 5, 68, 131, 32 ],
        "text": "I am a button" } ],
    [ "listen", "w4", { "Selection": true } ]
  ]
}

You can see that the create operation already contains the initial properties for the Button. With the listen operation, the client is informed that there are Selection listeners attached. When the button is pressed, the client will send this message to the server:

{
  "head": {
    "requestCounter": 1
  },
  "operations": [
    [ "notify", "w4", "Selection", {
        "shiftKey": false,
        "ctrlKey": false,
        "altKey": false
      } ],
    [ "set", "w1", {
        "cursorLocation": [ 121, 104 ],
        "focusControl": "w4"
      } ]
  ]
}

A more detailed description of the protocol syntax can be found in our wiki.

It’s important to point out that although most half objects in RAP are widgets, there are no UI specifics in the protocol. It is also used to synchronize service objects like the script executor or the geo location service in Tabris. The protocol no longer depends on HTTP. Even though RAP is still bound to HTTP, a future version could additionally work with other protocols.

With the completion of the protocol and the new RAP clients we decided to rename the project to “Remote Application Platform”. So the “R” in RAP now stands for “remote” and that’s how we see RAP: as a versatile platform for modular remote applications of all scales. These range from full-blown business applications with forms and tables in a web browser to minimal apps on a handheld device. All with the same programming model.

In my next post [RAP 2.0 Countdown (2/5)] I will introduce you to the interfaces that constitute the pillars of the RAP 2.0 API.